Gold Plating – The Quickest Way in Tarnishing Your Project's Reputation

“I thought this feature would be useful to our customer/user”

“We gave them more than they ever asked for”

“They didn’t ask for this, but I already had it built so I just threw it in”

Most people work hard to impress, but the lines above are examples of gold plating. Gold plating is the process of over-delivering during a project by adding additional scope without the users request. It is the silent and deadly assassin of far too many projects.

A feature implemented without proper controls often lacks testing, thus increasing the odds of producing a defect prone product. Have you considered the lifecycle costs of this small feature or enhancement you are throwing-in? Not only do you need to consider the initial time to implement, you must also analyze the impact to all of the following:

– User acceptance effort and duration
– Product documentation (user manuals, solution documents)
– Attack surface of the product. Larger entities have a greater attack surface. More areas/moving parts to fail
– Upgrade complexities and costs
– Support time and frequency of errors
– User adoption percentage. More difficult to understand and adopt.

Most engineers, developers and consultants do not consider the full impact of the feature or enhancement. They often do not bring it to the attention of the project team and all the important project control processes are missed. Gold plating is often committed by the junior resources of a project. They have the most to gain from looking like rockstars and the least likely to feel the consequences. It is the project, product and/or program manager who feels the brunt of the lifecycle costs. As a manager it is therefore imperative that you enforce the values of process and reiterate the importance of scope control.

So then, having considered all of the above. If the customer didn’t explicitly request that feature, are you sure its worth all the risks?

Nate

See wikipedia http://en.wikipedia.org/wiki/Gold_plating_(software_engineering) for more information.

Opportunities to Energize

As the saying goes “A Change can be as Good as a Rest“. One of the reasons why, is because being part of a change can be an energizing experience. A new job, a new office location, or a new project can often put a bounce back in your step. Think of these experiences as “Opportunities to Energize”

To understand the impact of change it is important to remember that humans are “creatures of habit”; we find something we excel at, where we are comfortable and we try to hang on until the sometimes bitter-end. This is an envious trait, due to the fact these people persevere and are committed, but have you ever wondered what it might be doing for their well-being or productivity?

Ask yourself these 3 questions to determine if a change may be in your best interest:

1) “When was the last time I stepped outside my comfort-zone?”

If a long time has passed since you last challenged your comfort barriers then think hard about trying something new. Stale, or dare I say “boring” lifestyles are rarely energizing or exciting. Successful individuals don’t settle for the status quo; they take chances, and make changes within their life. Think about the mentors or role models in your life, I guarantee they have stepped outside their comfort zone on multiple occurrences.

2) “Am I happy in my current environment?”

Are you truly happy with your lifestyle, your work life and your future direction? If there are any doubts in your answer to this question, dig deeper into this reservation and you may be surprised with what you uncover.

3) “Do I know of a change I should make”

If there is an change you have been questioning at length, this is usually a good indication it could be an “Opportunity to Energize”. Remember that sometimes opportunities present themselves in the most unexpected locations.

Your answers to the above questions will help you determine the positive impact of a change in your life.  I would love to hear from you, what sort of change in your life energized you the most?  Until next time…

Nate

What Got You Here Won't Get You There

So you have progressed within your company, been praised for your innovative thinking, technical skills, perhaps even your ability to sell a product.  Everything is going well, so you live by following the motto:  “If it isn’t broke, don’t fix it.”  Unfortunately, this is the flawed reasoning of far too many people.

The problem? “What Got You Here Won’t Get You There”  According to Marshall Goldsmith’s book, as we progress in our careers, the issues that hinder our advancement are usually not our lack of technical knowledge, but long standing personality traits that affect the people around us and our ability to lead to our full potential.  When was the last time you heard of a CEO being hired based on his proficiency in C# programming, SQL server or COBOL?  Likely never – and that is because in all levels of management, most top leaders hold the job because they have proven  that they have the interpersonal skills necessary in leading a team of people towards a collective goal.  Sure, everyone has their weaknesses, and no single person is perfect.  Truly great leaders recognize this, and almost all have at one point in their career started down a path of self-improvement to limit their personal quirks, so their quirks do not limit their potential.

Marshall’s book highlights 20 common personality traits found in high-performing individuals.  Through his extensive consulting practice, Marshall has found that most individuals will be guilty of up to 5 of these offences, but rarely more than that.  Here are just 5 of 20 common personality flaws that limit leadership potential:

1. The constant need to win
2. Failure to provide proper recognition
3. Ineffective listening
4. Clinging to the past
5. Adding too much value

* All 20 personality traits are thoroughly described in Marshall Goldsmith’s book “What Got You Here Won’t Get You There”

The route forward? Like most obstacles in life, resolution can only be achieved after the problem is acknowledged.  Usually before someone can admit there is a problem, the individual needs to see, feel, or hear the pain it causes those it affects.  In the business world, we do this through formal 360 degree feedback.  Best if performed through a third-party, feedback is an important tool in determining how other people feel about you.  From this feedback you can spot trends amongst responders, which will help you prioritize the top areas for improvement.

Once you determine the top 1 or 2 areas for improvement the next steps are to create a plan towards improvement.  Marshall recommends that all improvement initiatives start with a sincere apology to those you have affected.  As I am sure we all have experienced, a true heartfelt apology can go a long way in mending strained feelings.  In the case of self-improvement the act of apologizing performs a number of things beneath the surface:

• Ensures that you acknowledge the fact that there is a problem or room for improvement
• Tells those affected you recognize the problem
• Tells those affected you want to change for the better
• Makes you accountable towards improvement

I recommend everyone read Marshall Goldsmith’s book, perform the 360 degree feedback, and follow-through on at least one self-improvement initiative.  Since starting my own journey towards improvement in two of my less desirable personality traits, I can already notice the difference in my professional the personal relationships.

I wish you all the best as your journey on your own self-improvement path.

Cultural Diversity and Team Dynamics

Having lived in the multi-cultural city of Toronto, Canada the past 13 years, I have witnessed how cultural diversity can work in enhancing everyday life.   Also, through my experience in building software development and consulting teams, I have learned there are many benefits to team dynamics of embracing cultural diversity.  Here is a list of 5 common benefits:

1.  Saving Face

In many countries, the concept of “Saving Face” is important.  Especially true within Asian cultures, this trait often motivates team members work harder in solving difficult challenges and overcoming technical obstacles.  It is however important to ensure team members are not afraid to speak-up when they are unclear on a particular issue. Asking questions is not a sign of failure; it will enhance their knowledge, allow them to produce better results, therefore saving face in the long run.

2.  Fresh Thinking

Having recently returned from a trip to South-East Asia, it was interesting to note how common engineering, technical and transport challenges were solved differently than that of western countries.  Team members from other parts of the world have lived with and experienced all sorts of different solutions to everyday problems.  By pulling from their previous knowledge they can bring fresh new thinking to challenges your business may be facing, however big or small.

3. Motivation to Succeed

I consider this point to be a by-product of cultural diversity.  In many cases immigrants have moved from their native country due to unrest, or to pursue opportunities to provide a better life to themselves and their family.  In many cases they have sold everything to afford this new lease on life, and these individuals are therefore motivated to “Make it Work.”  Since so much is riding on the success and experience gained, these team member often bring an enthusiasm and motivation to succeed which can propel themselves and the entire team through tough, challenging projects.

4.  Enhance your Team or Corporate Culture

An important part of any successful company is a healthy corporate culture.  What better way to build or enhance your team or corporate culture by introducing some “real” culture.  Do this by embracing cultural holidays, sponsor cultural festivals, or have pot-luck lunches where each team member must bring one food item from their native country.  These sorts of activities bring teams together, and help team members feel part of the overall corporate entity.  Highlighting the cultural differences within a team enhances awareness within employees that each person is contributing, each person is unique, and each person is valued.

5.  Think Globally, Act Locally

As a recent financial crisis has demonstrated, companies are increasingly operating within the greater world economy.  Therefore, the impact of truly understanding and effectively marketing to each unique culture is pronounced.  Cultural diversity doesn’t just happen with outsourcing to a far away land – far from it.  The best type of cross-culture teams are those where the members are co-located and can lend their unique view points in a timely manner.  Hiring local talent that have diverse cultural backgrounds allow you to compete efficiently in today’s global marketplace.  Think about this:  Maybe the next time you are pondering expanding into a new country, your engineer from Malaysia may be your best asset, and not necessarily for his engineering skills.

An interesting note in closing – I once managed a software development project with a team of 8 developers. Within the team we had a representative from 5 different continents.  That is at least one person from every continent in the world except Australia and Antarctica.  We also proudly represented 5 different religions.  And remember this is from a team of only 8 people!  I hope you embrace your own culture and those around you so you may learn, grow and enhance the team dynamics for which you play an important role.

Monitoring Source Control for Enhanced Agile Visibility

Many of today’s agile software suites have the ability to integrate with various source (revision) control systems.  In theory, this allows the agile team visibility into code updates through their check-ins, but most importantly it matches each check-in to the applicable user story, iteration story or task.  In practicality however, there are some ground work items which must be in-place to benefit from this functionality.  Just like CRM or ITSM software implementations, a process must be in place before the software will show true return-on-investment (ROI) and long term user adoption.

The following process items are important if you want to use your source/version control system to enhance the visibility into your agile development:

1.Each team member must have their own source control login

Although it may go without saying, each team member must have their own login to the source (revision) control system.  Without this, there is not traceability to which user contributed to the user story, iteration story or task.

2.Comments, Notes, Messages on each Check-in

A long standing practice in programming is that code should be commented to enhance readability and therefore maintainability.  Why should a check-in to source control be any different?  The comments on each check-in should be detailed enough to indicate a summary of the changes for what is being checked in but not too detailed that it takes more than a minute or two to write.

3.Story or Task Reference Number

Along the same lines as point #2, each check-in should link to the unique reference number for the applicable user story, iteration story or task.  Every source control software system & agile software suite seems to handle this differently with some systems reading the card # or story # directly from the comments box and some having a specific field to capture this data.

Now What?

If your agile software suite supports an integration to your source control system than you can monitor check-ins directly from within.  If however you are limited to what your source control provides, so try to find a view that provide a running list of checkins or use a tool like SVN-Monitor (which I highly reccomend).

Start looking for the following things and soon you will see the power of this new data feed.  Just a few of which are:

1)  Compare Standup Meetings to Checkins

Compare what is said at your daily standup meetings to what is being checked-in.  This is not a matter of not trusting your team, but simply providing more granularity to standup updates.  Is there a team member who’s standup’s seem week, but checkins prove otherwise?  Perhaps you’ve noticed a developer that recently checked in a large item but forgot to mention the change during the standup?  Use this insight to mentor your team members of the importance of standup meetings, and improve you Agile adoption.

2)  Maintain Visbility During Busy Periods

During busy periods or very quick iterations (less than 1 week), the team may find tracking development tasks in the agile tool too tedious.  You know their doing work, and by monitoring source control you will get a good sense of the progress on user & interation stories even if they aren’t tracking it in the agile tool.  Do not let the team slip on tracking progress on user & iteration stories however!

3)  Metrics on Developers/User Story, Check-ins/User Story

As they say you can have “Too many cooks in the kitchen.”  Any experienced developer or team lead has been part of this a time or two.  If too many developers are working on one piece of code, sometimes they can interfere with each others development.  The ultimate result is code which is complex to read and more prone to defects.

Now to take this back to Agile… Ever wonder how many developers should contribute to a single user story?  Too few and you create silos of knowledge, too many and you may find challenges maintaining the code implemented in the user story in the future.  In my experience, I try to stick to no more than 3-4 developers per a 3 week user story.  Monitor your metric and find the balance that works best in your unique environment.  Remember no size fits all.

You can monitor a simular metric of # of check-ins per user story.  Mainly with this one metric you will want to watch for trends between user stories and you will likely find more complex user stories have more checkins.  You may therefore want to keep a watchfull eye on the release of these user stories.

I hope you find some concepts that you can leverage in your environment.  Until next time….

Nate

Rapid Development (My Retrospective)

Many years ago I was introduced to the concept of rapid development.  At the time, my brother-in-law who also happened to be my manager presented me with this blog title’s namesake book “Rapid Development” by Steve Mcconnell.  I remember bringing the book with me on a business trip to Chicago and beginning the journey.  I was intrigued by the concepts presented by the author and the common sense suggestions to increasing development efficiencies.  I will not go into the details of the book, but if you are interested it is worth the read, even though it was published over 10 years ago in 1996.

At the time, I was implementing some of the concepts presented in the book.  I was part of small 3 member development & implementation team of CRM software.  We practiced short iterations, delivered high-risk features early, and regularly prototyped our user interface designs.  I continued development for many years, implementing CRM & service desk systems in many varying industry verticals.  Eventually I moved onto project management, and now am the program manager overseeing the development & operations initiatives at ThinkITSM.

At ThinkITSM we decided very early on into the development of our SAAS platform that we wanted to formally adopt Agile software development practices.  We started by implementing the quick-win formalities like “stand-up” meetings, set iterations timings, and story boards (KANBAN).  We then focused our attention to acquiring some tracking software (Mingle), and implementing continuous integration with cruisecontrol.net.  It has now been almost 10 months since implementing Agile.    If you polled any member of the development team, without a doubt you would hear resounding agreement speaking to the benefits this process has had for us.

Its now very nice to look back and see the path I took to eventually adopting Agile development practices; from my early days programming, when I prototyped user interfaces just because it seemed like the logical thing to do, to today where stand-up, iterations, and CI are like second nature.  They say what’s old is new again, for me this truly is the case.

Hello World!

Well, since I’m a developer at heart; a hello world to all of you!   From time-to-time I will be posting articles here that I find interesting or enlightening. I hope you enjoy.

Stay tuned for more.

Nate