Tag Archives: Global software development

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

 

QSM (Quantitative Software Management) 2014 Research Almanac Published this week!


Over the years I’ve been privileged to have articles included in compendiums with industry thought leaders whose work I’ve admired.  This week, I had another proud moment as my article was featured in the QSM Software Almanac: 2014 Research Edition along with a veritable who’s who of QSM.

This is the first almanac produced by QSM, Inc. since 2006, and it features 200+ pages of relevant research-based articles garnered from the SLIM(R) database of over 10,000 completed and validated software projects.

Download your FREE copy of the 2014 Almanac by clicking this link or the image below.

almanac

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

If IT’s important – get a second (or third) opinion!


I’d like to share with you my latest  post on the QSM (Quantitative Software Management) blog – let me know what you think!

-Carol

1st in the series

1st in my new series – here’s the URL:

http://www.qsm.com/blog/2013/ask-carol-if-its-important-get-second-opinion

What Can Goldilocks Teach about Software Estimating?


goldilocks

http://www.qsm.com/blog/2013/what-can-goldilocks-teach-about-software-estimating

Comments?

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.

Whats behind Project Success: Process or People?


Depending on who or what you read, most software and systems projects (over 50%) end up as unsuccessful/failures:  over budget, late, and/or fail to meet the user needs.  As a worldwide phenomenon, studies continue to expound on why projects fail (poor requirements, underfunding, overoptimistic estimates, unreasonable schedules, lack of management commitment, etc.) but few studies focus on what it takes for projects to succeed.

What do you think makes a project (of any kind) successful?  What is more important to project success:

1. The processes involved (e.g., formal project management, standards, shortened development life cycles, agility…); or

2. The people involved (e.g., the right team makeup, a good mix of skills, a motivated workforce, engaged users); or

3. Trust (e.g., collaboration rather than negotiation between customers and suppliers, reliance, cooperative teamwork; communication); or

4. Something else (e.g., other factors such as CMMI, tool sets, unlimited budgets, Steve Jobs on the team, …); or

5. Some “magical” combination of the above; or

6. None of these?

Across industries and across the world, is there a difference in what makes a project successful?  Are there certain factors that predispose a project for success (or failure?)

What do YOU think?  Inquiring minds are interested in hearing from you… (please post a comment or send me a private email to dekkers (at) qualityplustech (dot) com).

Thank you!
Carol

Walking on Eggshells – a Normal part of Business?


We have all been there – walking on eggshells to avoid outbursts from  a boss, co-worker, or client.  So we skirt the issue, pretend the bad behavior doesn’t exist, ignore the problem, and spend extra time planning how to present an issue so that the person in question doesn’t explode.

While I know that this type of behavior is rampant in business (I’ve experienced it more than once!) – it has serious (and expensive) consequences in the IT industry.  The repercussions stemming from having to “walk on eggshells” to avoid the potential wrath ranges from minor  “oversights” to full scale project failure.

The Challenger disaster is one such failure where group-think and avoidance of conflict ended up costing lives and millions of dollars.  A video chronicling the group think behavior depicts the group-think behavior and steps are taken in companies to address such behaviors. This is all good.

The Walking on Eggshells “syndrome”

Aside from the pressures of group think that encourages teams to conform and cooperate with a single mindset, the “walking on eggshells” syndrome is seldom documented or even discussed.

We all know at least one offender in our workplace!  The offending person may be a narcissist, a control freak, a bully or just plain immature. No matter the clinical diagnosis, our boardrooms and our production labs suffer greatly from their presence.

How much time and money could be saved by confronting these people and addressing the cost of their ‘verbal diarrhea’? Here’s the type of situations I mean:

  • Not raising issues:  “How can we possibly bring up the design flaw for this software now?  The project sponsor will yell and rant if the project is late. Remember how he “freaked out” at the status meeting last month?  Keep going and we’ll address this as an enhancement.”  Cost: could be significant.
  • Cutting corners: “There is no way we can finish the project within the approved budget.  We had no idea that xxx would be so complex, but the steering committee will fire us if we ask for more money. Let’s just cut testing so we can finish the project.”  Cost: could be critical if public safety is at stake.
  • Perpetuating the myth that project plans are right:  “The project plan was based on incomplete data that seemed right six months ago. Now we know more, but with a fixed budget and schedule, we’re stuck. The client will explode if we bring up that the plans were flawed. Let’s just do what we can.” Cost: Corporate learning will never happen (Einstein: insanity is doing the same things over and over and expecting different results.)
  • Skirting accountability: “We messed up on the schedule because we had to program that module 3 times.  I couldn’t understand what they wanted until this time, but we can’t tell Bob because you know how he gets.  I hate it when he yells in a staff meeting.” Cost: could be significant to minor.
  • Wasting time and money: “This project is doomed – the users told us they won’t use the system even if we finish it. The rationale and vision for the project are no longer correct (it’s a dog!) but if we tell the boss about it, you know how she will blame us. I don’t think it is even worth trying to explain it.  Just keep going.”  Cost:  priceless – time and money could be better spent on REAL work!

What a colossal waste of time, money, energy, and morale “walking on eggshells” is to a business!  It is not an easy situation to fix or address – especially when we are talking about people in power who behave badly.

Walking on eggshells should never be part of the way of doing business!  What is the solution?

If YOU were the king of your IT kingdom, what would YOU do?  I’ll publish a summary of responses – add your comments below – or send them privately to me by email to dekkers (at) qualityplustech (dot) com.

Have a productive week!

Carol

Common-sense Leadership: Respond not react…


A big benefit to teaching leadership and communication workshops to adult professionals is continuous learning: every time I teach a class, new revelations come into focus.

One such “aha” moment (where one realizes something that may not have been obvious before) is that Leadership is really about learning to Respond to a situation or stimulus instead of automatically Reacting.  Why is this important?  Responding is the thought intensive process of actively listening, pausing, and then gathering ones “thoughts” before speaking.  Gathering of one’s thoughts involves the neocortex (center) of the brain whereby we override the reptilian (instinctual) brain and the limbic (emotion-induced) brain, and hopefully create a response less prone to immediate and autonomous reactions (based on instinct or emotion).

Considering how eastern cultures (such as Japan) seem to habitually pause before asking questions at a conference or before coming to an agreement gave me “pause” to reflect on how this practice conveys power and respect – and is one often used by practised politicians at press conferences.  This results in less “eating one’s premature words” and less damage control as opposed to when one speaks too hastily or without due thought.

This is a common-sense tip on how to practice better leadership in your own workplace no matter your position:  remember and practice active listening (if you are thinking of what you are going to say – you are not listening!), pausing, gathering your thoughts (and perhaps even saying “please give me 15 seconds to gather my thoughts”) and then thoughtfully responding.

Food for thought – what do you think?  Could this be helpful in your workplace?

Carol