Category Archives: software development

Combining Soft Skills and Hard Tools for Better Software

One of the more interesting topics in software development (at least from my perspective) is the culture of the industry.  Seldom does one find an industry burgeoning with linguistics majors, philosophers, artists, engineers (all types – classically trained to self-named), scientists, politicians, and sales people – all working on the same team in the same IT department.

This creates an incredible diversity and richness – and leads to sometimes astounding leaps and bounds in innovation and technological advancement, but it can also create challenges in basic workplace behavior.  This post takes a look at the often overlooked soft skills (empathy, leadership, respect, communication, and other non-technical skills) together with technical competencies as an “opportunity” (aka challenge or obstacle to overcome.)

It was published first on the Project Management Institute (PMI) Knowledge Shelf – recently open to the general non-PMI public.

soft skills

Added bonus here:  I referenced the You Tube 2013 University of Western Australia commencement address by Australian comedian/actor Tim Minchin at the University of Western Australia in 2013 in my post (he shares his 9 recommendations to graduates, my favorite -and the one I quoted – is #7 Define yourself by something you love!)  I believe it’s worth the watch/listen if you need to take a break and just sit back and think about soft skills during your technical day. (Warning to the meek of heart – it’s irreverent, offensive, and IMHO, bang on in his core sentiments.  If you’re offended, I apologize in advance!)

If you’d like a pdf copy of the post above, please leave me a comment with your email address!  (And even if you don’t, I’d love your opinion!)

Have a great week!

Carol

What Goes Around Comes Around in S/W Development... Let's minimize the rework with Lean!

If you don’t have time to do it right, when will you have the time to do it over? (aka Do it Right the First Time).  There has to be a better way (and there is)!

Rework… what a waste (literally)!

Rework is one of the most frustrating aspects of software and systems delivery, especially when you consider that over 40% of IT development effort is spent doing rework (stats hover around 45% according to published reports from the Department of Defense).  Why is rework so high in software development?  There are many reasons including incomplete or unclear requirements, customer changes (since the beginning of the project), and elongated timelines.  Can you imagine what our life would be like if every industry was plagued by this amount of rework?

  • Construction would take two to three times as long to complete (imagine construction without sealed engineering drawings!)
  • Medical surgeries would mean that patients would have to endure multiple operations to get the original job done properly (I can hear the lawyers applauding already)
  • Clothing manufacturers would have to double their prices because of waste due to improperly cut or sewn garments

Few other industries would tolerate this level of rework…  yet IT not only tolerates rework (in the hope of delivering a product that achieves high customer satisfaction), but most projects end up late, over-budget, and delivering unnecessary or incorrect functionality.  Often projects are rushed through when schedule crunches and rework overwhelms them, or functionality or quality is sacrificed to finish on time.  In either case, results include inadequate software product releases, with costly follow-on maintenance to correct poor quality or product deficiencies.

When Phillip Crosby wrote his award-winning book “Quality Is Free”, many professionals mistakenly thought the title meant that there is no cost to building quality into product development. Today we know that Crosby meant that quality pays for itself in the long run – and ultimately reduces product development costs.  Unfortunately, the idea of doing things right the first time is still a pervasive challenge in IT – and not all the blame lies with the software development team.  Rework, poor quality, crunched schedules, inadequate budgets, and poorly documented requirements are a shared responsibility of both the business customers (who need the software) AND the software developers.

Since the mid-1900’s, other industries such as manufacturing embraced evolutionary approaches to reducing rework, shortening development delivery cycles, cutting out waste and delays, and scoping out smaller bits of functionality to deliver incrementally, with transformational results.  Today a handful of the best practices have been adapted and tailored for use in software and systems development and offer similar transformational results to the IT industry.  Approaches like Kanban, LEAN, JIT (just-in-time), and others  make complete sense and increase team morale and the quality of the resultant software products, while reducing waste.

If you’ve never heard of Kanban, Outcome-Driven-Development, Lean Software and Systems Development, or a myriad of other named approaches, you might be out of touch – but you are also in luck, because there are resources available to get you quickly up to speed.

I’d like to mention a couple of notable resources here:

LSSC11-logo1. The Lean Software and Systems Consortium (LeanSSC) is hosting their second annual Lean Software and Systems conference (acronym LSSC11) to be held 3-6 May, 2011 in Long Beach, CA at the Hyatt Regency Hotel. Here’s a few important links that may be of interest:

2. Upcoming FREE webinars:

The Lean Software and Systems Consortium (LeanSSC)is hosting a series of FREE webinars commencing on January 18, 2011 to educate professionals who want to improve the productivity and quality of their IT delivery. Register today for one or all of these webinars.  Here’s the upcoming schedule of topics and dates for the webinar series:

If you are like me and catching up with all the Lean terminology…

I’m going to be posting frequently in the coming weeks and months about concepts, ideas, and general software development related to Lean, Kanban, Multi-modal approaches, and other topics – I hope that these will help you to catch up and help your company leapfrog ahead of your competition in software development.  And, I’d like your comments and feedback on what you think!

I’ll end this post with a couple of (what I consider) essential snippets:

  • Lean Software & Systems Consortium (LeanSSC) is a global, non-profit organization whose mission is to promote and create awareness of Lean Thinking applied to software and systems engineering and associated competencies.
  • From David J. Anderson on Yahoo discussion group kanbandev:  “I’ve jokingly referred to Kanban as “Outcome Driven Development” recently on Twitter. Some people thought I was joking 😉 as the ODD method hardly seems sensible! You are deciding the outcome you want (from a small change). You want code tested early to avoid it going stale. You want it tested while it is fresh in the minds of those who created it. You also want testing exposed as a bottleneck. You want the test bottleneck made visible/transparent/explicit. You seek to do this through a process (or system) change that introduces a WIP limit. Your hope (based on an understanding of theory, so it is a belief based on a scientific understanding) is that by setting a WIP limit you will expose the bottleneck and provoke further discussions that will change behavior, resulting in the outcome you desire. Your leverage point is the WIP limit. The WIP limit is the actuator you are using to stimulate emergent (desirable) behavior.”

Happy 2011 and I hope you’ll pass on this post to others who may be interested.  Join us on one of the Facebook, Plaxo, LinkedIn or other LSSC11 groups.  You’ll be glad you did!

Regards,
Carol Dekkers
Share

Ever had this problem in Software Development?

software development videoHave you ever felt that the business side of software development just doesn’t understand what’s involved?  Watch the short video I created (just click on the “photo” above) and let me know if this is anything like what you’ve ever experienced.

It’s no wonder that so many projects end up over budget, behind schedule and delivering a product that just doesn’t fit.  One solution is scope management.  Call or email me today for a free white paper about Scope Management (dekkers@qualityplustech.com).

I know the video is tongue-in-cheek but I’d like to hear your comments!

Have a good day,
Carol
Share

The "Dog Chasing its Tail" Syndrome in Project Estimating

Software estimating is plagued by dysfunction, not the least of which is estimation based on under-reported historical hours from previously completed projects.  See posting IT Performance Measurement… Time Bandits for a discussion about this problem.

BUT, other problems are prevalent when launching a project estimating initiative which I call the “Dog Chasing Its Tail” syndrome.  It symptomizes dysfunctional project behavior that is established and continues to be reinforced to the detriment of the organization. As a result the pattern repeats and process improvement is seldom realized.

What is the Dog Chasing its Tail Syndrome? It’s a noble goal to increase the predictability and reliability of project estimates – when estimating is based on sound principles.  However, estimating is often a misnomer for what should be called “guesstimating” because the data on which estimates are based is sketchy at best.

Here’s the process epitomized in the “Dog Chasing its Tail”:

1. Incomplete (or preliminary) requirements and sketchy quality/performance requirements. While preliminary (no formal requirements or  use cases are known), it is customary for management (customer or supplier or both) to demand a project estimate for budget or planning purposes. Labelled initially as a “ball park estimate” (a rough order of magnitude (ROM) guess of whether the effort is going to be bigger than a breadbox or smaller than a football field), the sketchy requirements are used as the basis to get the ROM.

2. The (Guess)timate becomes the project budget and plan. While management initially understands that an estimate is impossible without knowledge of what is to be done, estimators contribute to the reliance on the guesses by providing them with a feigned level of accuracy (e.g., if requirements span a total of two sentences, the resultant estimate may include hours or dollar figures with the ones digit filled in.  As a result, too often the (guess)timate becomes the approved upper limit budget or effort allowance.  Of course these figures will be proven wrong once the solid requirements are documented and known, but we are now stuck with this project estimate.

3. Changes challenge the status quo budget and schedule. When a change or clarification to requirements emerges (as they always do when human beings are involved), there is often a period of blame where suppliers allege that the item in question is a change (addition) to the original requirements on which the estimate was based, while the customer alleges that it is simply clarifies existing requirements.  Of course, neither one can be proven correct because the requirements on which the estimate was based were sketchy, incomplete and poorly documented. Once the dust settles and it becomes clear that the item will impact the project budget and schedule, the change/clarification is deferred to the next phase (“thrown over the fence” as an enhancement to be done in the next release) where it will be poorly documented but we will estimate it anyways, and so the cycle continues.

Dog chasing its tailIf you’ve ever had a dog – you know that this is similar to a dog-chasing-its-tail whereby the behavior goes on until either the dog gets tired or gets distracted by other things going on (such as food being served).  As smart software engineers we ought to be smarter than dogs!  And, given a scope management approach, we can be!  Break the cycle off dysfunctional estimation and investigate scope management – you and your customers will be glad to move forward rather than facing the insanity of repeating the same process over and over and expecting different results (along the lines of the Einstein quote!)  See www.qualityplustech.com for information on scope management training and resources available to break the “Dog Chasing its Tail” syndrome on your projects

Watch for the upcoming post on the hidden dangers in project hours…

To your successful projects!

Carol

Carol Dekkers
email: dekkers@qualityplustech.com
http://www.qualityplustech.com/stage/

Carol Dekkers provides realistic, honest, and transparent approaches to software measurement, software estimating, process improvement and scope management.  Call her office (727 393 6048) or email her (dekkers@qualityplustech.com) for a free initial consultation on how to get started to solve your IT project management and development issues.

For more information on northernSCOPE(TM) visit www.fisma.fi (in English pages) and for upcoming training in Tampa, Florida  — April 26-30, 2010, visit www.qualityplustech.com.

Contact Carol to keynote your upcoming event – her style translates technical matters into digestible soundbites, with straightforward and honest solutions that work in the real world!
=======Copyright 2010, Carol Dekkers ALL RIGHTS RESERVED =======

IT Performance Measurement - Don't let time bandits prevail...

Here in FL, Sunday is one of my favorite days to sit outside on the deck overlooking the mangroves (yes, spring break weather is FINALLY here!) – and read the bulging Sunday newspaper.  I am always intrigued by the many topics in Sunday’s edition, and there’s always generalist stories that remind me of something that happens with software.  This week was no exception.

I’ve nevTime Banditser seen the syndicated column called “The Ethicist” by Randy Cohen (syndicated from the NY Times Magazine), but today’s column headline:  “Underreporting hours worked puts unrealistic goals on others” caught my eye… just the title reminded me of one of the biggest problems with IT measurement:  project hours in IT are typically under reported because of unrealistic project budgets, overtime rules, accounting practices, etc.  (In my experience with measurement and productivity work – this is part of what I call the “Dog Chasing Its Tail” syndrome but more about that in another post.)

Back to the Matter at hand… In this week’s column, (originally published in NY on March 11, 2010, and in my St. Petersburg Times March 14, 2010), Randy Cohen is presented with an ethical question:
“As a manager at a large company, I work far more than the required 40 hours a week, but report only 40. If I reported my actual hours I could be penalized financially for letting my projects run over budget.  Company policy states… <snip> … is there a problem with simply declining to mention some hours when I did work?”

The crux of Randy’s answer (as it related specifically to IT Performance Measurement for me) was “By underreporting your hours, you create a false sense of your efficiency.  The company now believes that you are able to complete your weekly tasks in 40 hours. But you are not. Your deception thwarts the company’s reasonable interest in assessing your performance”.  To use a Canadian expression Bang On with your response Randy! (to read the entire article by Randy Cohen, click here.)

This is one of the most pervasive problems when tackling software project estimation – using reported project hours as the basis for new project estimates (when the actual hours are much higher). Most people would see the folly of estimating the cost of a new based on the mortgage of a house down the street (you don’t know how much was the down payment!), but overlook the hazards of doing the same thing when estimating a software project based on under reported hours.  Both fall victim to the wrong foundation for estimating.

Before you embark on a process improvement initiative that targets Predictability and IT project Estimating, make sure that you know all the facts before you waste valuable time or energy compounding the existing problems and ignoring the real status quo.  Become knowledgeable about the issues (call or email me if you need a starting point or resources.)

To your successful projects!

Carol

Carol Dekkers
email: dekkers@qualityplustech.com
http://www.qualityplustech.com/stage/

Carol Dekkers provides realistic, honest, and transparent approaches to software measurement, software estimating, process improvement and scope management.  Call her office (727 393 6048) or email her (dekkers@qualityplustech.com) for a free initial consultation on how to get started to solve your IT project management and development issues.

For more information on northernSCOPE(TM) visit www.fisma.fi (in English pages) and for upcoming training in Tampa, Florida  — April 26-30, 2010, visit www.qualityplustech.com.

Contact Carol to keynote your upcoming event – her style translates technical matters into digestible soundbites, with straightforward and honest expertise that works in the real world!
=======Copyright 2010, Carol Dekkers ALL RIGHTS RESERVED =======

Crosstalk article on Scope Management

CrossTalk - The Journal of Defense Software Engineering

CrossTalk Jan/Feb 2010 Scope Management: 12 Steps for ICT Program Recovery

by Carol Dekkers, Quality Plus Technologies, Inc.
Pekka Forselius, 4SUM Partners, Inc.

ABSTRACT:
The information and communications technology (ICT) world is “addicted” to dysfunctional behavior and the problem is spreading globally. The sad truth is that the parties in the ICT relationship (the customer and the supplier) are largely co-dependent on a pattern of dysfunction characterized by ineffective communication, fixed price contracts with changing requirements, and eroding trust. This article focuses specifically on the northernSCOPE TM 12-step process for ICT program recovery.

For more information on northernSCOPE(TM) visit www.fisma.fi (in English pages) and for upcoming training in Tampa, Florida  — April 26-30, 2010, visit www.qualityplustech.com.

To your successful projects!

Carol

Carol Dekkers
email: dekkers@qualityplustech.com
http://www.qualityplustech.com/stage/
Contact Carol to keynote your upcoming event – her style translates technical matters into digestible soundbites, with straightforward and honest expertise that works in the real world!
=======Copyright 2010, Carol Dekkers ALL RIGHTS RESERVED =======

Measuring IT Performance

Quote for those tasked with implementing a sustainable measurement program with positive ROI:

“When we seek generalities we fail.
When we seek specifics it is easier.
When we measure performance, performance increases (Hawthorn effect).
When we measure and record performance, performance accelerates.”

Source: Anonymous.

Where Should one Start when Tackling a Software Measurement Program?

Overheard at a recent IT software conference:

  • “Okay, so I guess the 1st step is to measure function points” (Dekkers’ comment: Sorry, wrong approach. The 1st step is to figure out the Goals that you want to achieve with measurement.  Think of this like going shopping – what do you need to buy – you only make a grocery list of what you need once you know what you want to cook. The same thing goes with software measurement! Deciding your goal (s) is the first step)
  • “It sounds like I need a measurement consultant but how do I choose one and what will it cost?” (Dekkers’ comment: There are more than enough eager software measurement consultants who will tell you their way is the best and only way.  One group touts themselves as the elders of software measurement and holds up their volunteer committee service as their mantra, while many of their consultants are hired guns – that is they are subcontractors who work freelance for the highest bidder.  Make sure to ask for (and check) references and ask those references what their ROI on the consulting group was BEFORE you take the salesman’s word for it!  Buyer beware – there’s some unscrupulous fat cats in the water who will take your money, implement useless difficult measures, and be gone leaving you holding a dashboard that doesn’t match what you wanted to achieve.)
  • “Software metrics sounds easy but the presenters make it sound hard” (Dekkers’ comment:  Software metrics is NOT rocket science or even difficult. Follow Goal-Question-Metrics (GQM) approach, engage a bit of targeted training, and take it one step at a time and you’ll see that you too can be savvy with software metrics and gain performance improvement.  Take a look at the FREE materials on Practical Software and Systems Measurement (PSM) from www.psmsc.com and from CrossTalk (www.hill.af.mil/crosstalk – search for software measurement and from the DACS (www.dacs.com) which are all US taxpayer funded initiatives for a starting point).

Make sure you take advantage of the many free article downloads at www.qualityplustech.com or send me a note at dekkers@qualityplustech.com before you hire a consultant to design a function point or software measurement program you’ll later regret.

To your successful projects!

Carol

For more information on northernSCOPE(TM) visit www.fisma.fi (in English pages) and for upcoming training in Florida, visit www.qualityplustech.com
Carol Dekkers
email: dekkers@qualityplustech.com
http://www.qualityplustech.com/stage/
Contact Carol to keynote your upcoming event – her style translates technical matters into digestible soundbites, with straightforward and honest expertise that works in the real world!
=======Copyright 2010, Carol Dekkers ALL RIGHTS RESERVED =======

Overcome CHAOS with scope management...

“Don’t waste even one heartbeat on things that don’t matter.”  Anonymous

 This quotation should be the mantra of software development – if only we could figure out what “in the customer’s eyes” doesn’t matter!

The Standish Group’s 2009 CHAOS report certainly didn’t bring any celebratory words:  After steady increases from a dismal 17% project success rate in 1996 to the 34% (a doubling!) rate in 2006, this year’s study reported a decrease to a mere 32% of projects being declared a success.

 What’s going on? With 60-99% of defects attributable to poor requirements, and 45% of development effort spent on rework, it is clear that somehow the customer side of the house and the development side are out of whack.  Worldwide, we could declare software development as a problem of epidemic proportions – especially as software pervades every aspect of our daily lives.  If we can casually launch a team of scientists to fix an ailing space station on a moment’s notice, and announce medical breakthroughs, surely the brains in software development should make strides in this area.  Take rework for example, currently hovering at an astounding 40% of software development effort – this means that while we do great work Monday to Wednesday every week, the remaining two working days are spent fixing and redoing the very work we just completed. The old adage – “if you don’t have the time to do it right, when will you find the time to do it over?” —  doesn’t seem to hold much water does it when almost half of every week is spent doing costly rework?

Here’s the crux of the situation – it’s not a matter of incompetence!  It’s a matter of the customers not being able to fully articulate what they actually need – and a matter of the suppliers not being able to deliver to requirements that are as sketchy as clouds.  BUT, there’s a solution that’s been successful in Finland and Australia called Scope Management – and I’ve mentioned this many times in the past… stay tuned for more information in the coming posts. And Scope Management training is coming to Tampa, FL in just a few weeks.  More to come!

For more information on northernSCOPE(TM) visit www.fisma.fi (in English pages) and for upcoming training in Florida, visit www.qualityplustech.com.

To your successful projects!

Carol

Carol Dekkers
email: dekkers@qualityplustech.com
http://www.qualityplustech.com/stage/
Contact Carol to keynote your upcoming event – her style translates technical matters into digestible soundbites, with straightforward and honest expertise that works in the real world!
=======Copyright 2010, Carol Dekkers ALL RIGHTS RESERVED =======

2010 - new year, new advances in software development?

As 2009 draws to a close, we’re left with an “interesting year” where budget cuts in early year gave rise to reduced program deliveries, but by midyear the customer demands for more functionality gave rise to a resurgence of development activity. 2009 saw the CHAOS report (www.standishgroup.com) declare a reduction in the percentage of successful projects, the first year in memory when success rates have decreased – not a good report card for the IT industry!

There’s hope however, and scope management (often the topic of this blog) continues to amass followers and successes in Finland. Yet another government department has embraced scope management processes in their procurement and software development, bringing to almost a dozen the number of federal government departments in the Scandinavian nation for which unit pricing, measurement based progress reporting, and formal change management has become a standard.

For information about the northernSCOPE(TM) approach to scope management on software intensive projects, visit www.fisma.fi and select the English tab.

Workshops will be offered in Q1 2010 for Certified Scope Managers (CSM) including the examination by the European Certificates Association by Quality Plus Technologies (www.qualityplustech.com).

Wishing you success in 2010! What will you do differently to make YOUR project succeed?

To your successful projects!

Carol

Carol Dekkers
email: dekkers@qualityplustech.com
http://www.qualityplustech.com/stage/
http://www.caroldekkers.com
Contact Carol to keynote your upcoming event – her style translates technical matters into digestible soundbites, humorously and forthright. View also Carol Dekkers’ general blog at http://caroldekkers.wordpress.com/ The Dekkers Report
=======Copyright 2009, Carol Dekkers ALL RIGHTS RESERVED