I was browsing through jobs on a freelance job posting site when I saw a post asking for a virtual assistant who can post comments recommending the business’ product on various internet sites.

It made me ask the question ‘who can we trust?’

So much money and time is spent on social media engagement that face-to-face customer service is deteriorating.  The focus is on increasing the numbers of virtual buy-in whether that be:

1. to your website
2. to your Facebook page
3. to your twitter updates
4. to your blog
5. to your LinkedIn profile

More and more businesses are spending time and money on SEO (Search Engine Optimisation) than physically going out there and making an impression.

Sitting here, a virtual assistant in a previous life and having learnt from my mistakes, I can say this:  if your profit margin is driven primarily by product sales than the virtual marketing strategy is perfect for you.  However, if your profit margin is driven primarily by service sales than get yourself out there.

Nobody is going to refer you if they don’t know you.

I’m logging off now.

tea breaks in abundance. release your workload. re-live your creativity

The day of the appointment

Process breakdown #1:

The GP asks ‘So why have you come to see me?’
‘I have come to get my blood test results.’ I reply.

Having told the receptionist last week the reason for the appointment, you would think that 1) this would be noted in my file, or 2) the blood test results would be printed out.

Process breakdown #2:

The GP accesses their internal database to find my file.  There are two lines: the receptionist created a new profile when updating my contact details instead of updating the existing profile.

Receptionist needs to be trained/re-trained on how to maintain the database.

Process breakdown #3:

The GP after 5 mins identifies the profile which has my results.  The GP then uses medical terminology (she is basically reading the results word-for-word off her computer screen).

Communication is key when establishing trust.  If you are in the business of improvement, speaking a language that can be understood without question will contribute greatly to achieving a positive result effectively and efficiently.

Process breakdown #4:

I ask the GP for a copy of the results.  The GP gets a few sheets, places them in the printer then proceeds to print them out.

Go back to Process breakdown #1.  There are two receptionists at the local medical centre.

Process breakdown #5:

The GP thumbed through the pages to make sure they were all there.

Documents should have page numbers.  If the complete document is important as in this case, then the page number should be as follows: Page X of Y.  Also, as in this case the identifier (record number) should appear in the header of each page.

Process breakdown #6:

‘How come you came to see me?’ (pause) ‘I mean why did you make an appointment to see me specifically?’ ‘Did you just ask to make an appointment to get your blood-test results and they [being the receptionists] picked me?’  The GP asked.

‘Yes.’ I replied.

In a pool of GPs, why should it matter which GP I see?  I (the client) am requesting to understand and receive a copy of my blood test results.  The data (blood-test results) is the constant.  The data does not change from one GP to another.

The breakdown in process flowed on from the front desk to the service delivery.  I walked past Reception and out of the medical centre happily knowing that I won’t be returning for a very, very long time.

tea breaks in abundance. release your workload. re-live your creativity

Why the change?

1. thestainedteacup.com blog’s content caused confusion for potential customers
   The content did not reflect the expertise of thestainedteacup.com in the service/s it is delivering.
2. The business was 100% virtual (no face-to-face contact)
   The previous blog served to show that there was a human being sitting behind thestainedteacup.com.  This is no longer required as thestainedteacup.com’s services is now a mix of virtual and face-to-face contact.

What will change?

thestainedteacup.com focuses on continuous improvement.  Going forward thestainedteacup.com blog will post information which focuses on Operational Excellence i.e. continuous business improvement.

Where did thestainedteacup.com blog’s previous content go?

thestainedteacup.com’s previous content has been imported into a new blog called Gypsy Wings.  You can still read anecdotes and access archived content by visiting Gypsy Wings.

Thank you

Thank you to the inspiring clients who have engaged in thestainedteacup.com’s services and continue to do so.

Thank you to the inspiring readers of thestainedteacup.com’s blog.

tea breaks in abundance. release your workload. re-live your creativity

Let’s fast forward to the hard times of today.  The Dow hovers around 13,000, a 30 year mortgage is less than 5%, GDP is 14 trillion dollars, inflation is less than 3%, and there are there are more than 138, 610,00 people employed.  This comparison seems odd doesn’t it?  It fails to explain the current malaise so something be missing.  It will seem obvious to most that debt is the key metric missing from the comparison but does that explain our dilemma?

These questions bring us to our first lesson from the school of hard knocks:

  “Money is not the problem”

This odd statement is best explained in the following scenario.  Suppose we have a student here at Hard Knocks University who lives in a 1400 sq foot home with two brothers, two sisters, mom and dad.  The family would have one phone (a land line), one car (a used station wagon), one television (23″) and the younger children wear hand-me-down clothes donated by the older ones.  The children are on a strict allowance and work add jobs around the community to bring in some extra spending money.

The above description is not that of a lower class, disadvantaged student.  It is an accurate depiction of a solidly middle class household of the kind where most baby boomers grew up.  They did not see themselves as poor, instead they realized they were far better off than their parents were at the same time in their lives.  They were happy; hence the popular TV show “Happy Days” which depicts the simple pleasures this generation enjoyed in the 1950′s and early 1960′s.

Has the present generation for all of its material wealth achieved greater happiness?  This is not even debatable.  If money was the issue the twelve trillion dollars spent by the Feds in the last four years would have solved all of our problems.  That money doesn’t bring happiness is equally clear. One need only look at Reality shows to see how truly unhappy we are.  Half of all of these shows depict average Americans at war with something.  Even the act of baking a cupcake (an art still practiced by little girls with their Easy-Bake Ovens) is enough to incite an aggressive act of war.  What’s next, Dollies at war, Tricycle wars?

The bubbles that burst in the late nineties and early two thousands demonstrated how dependent our economy is on consumer spending.  In both eras we saw excesses exercised by consumers who were driven to have it all (defined as having all of the stuff  they could possibly get).    Both generations were taken to the wood shed and taught a  hard lesson.  Capitalism distributes these hard lessons every 20 years or so and we are want to repeat these mistakes rather than learn a history lesson.  At Hard Knocks U we understand the value of history and thus our second lesson for the day:

“If you will practice self discipline you will not find yourself being disciplined by others”

Discipline does not mean being punished – unless you don’t have any of it.  At its core it embodies a form of self control that brings benefits.  These benefits occur over time and act like an investment that earns compound interest.  To reap this reward we only have to stay the course.  Discipline is not popular since it involves patience.  Patience is not popular since it involves self denial.  Self denial is not popular for reasons that will confound the reader once the many benefits that come from it are understood.

How do we get things going again?  Do we have the courage to commit to some good old fashioned hard work, patience, a dose of self denial and to realize that life is not stuff?   Does this sound corny and old school?  Perhaps, but the old school was operated by the greatest generation and they created a country that was the envy of the planet and they were happy.

Are we better today, than yesterday?

Do you really know the score of the game?

What are we doing today, to ensure we are better tomorrow?

Has anyone ever asked you these questions? Have you asked yourself?  If not, they are questions we should always be asking ourselves as lean thinkers.

I have been mulling this concept over the past month or so and have come to the following conclusion: the reason we can’t exactly articulate the score of the game is because we haven’t completed the cycle of practicing core lean principles:

• Seeing problems
• Fixing/solving problems
• Learning
• Sharing the learning to continuously improve

We spend so much time on the root cause analysis and working toward a solution that we tend to slack off on re-grouping with the team after the problem is solved. We need to re-group in order to gather learning points and ensure we have KPIs in place to measure our ongoing performance.

TIP : Be sure to not put too much pressure on quick result timelines when problem solving. Many times this leads to putting the wrong solutions into place or pushing the problem downstream.

So, how do we make sure we know the score of the game? First make sure you have a good handle on the following two items. Otherwise, you’ll  never know  the true score of the game:

1)      Have a clear definition from your customer of what they want and continually get updated feedback from them. Essentially they are telling you the rules and expectations of the game.

2)      Don’t be afraid of really understanding and documenting the current state and issues. You are sizing up your abilities to understand what needs to be updated, strategizing your game.

Now, most importantly, create your scoreboard. Follow these rules during creation. You can find these rules and further explanations in the previously mentioned book, People:

1)      Measure performance, not people.

2)      Create metrics that enable monitoring and improvement of the entire value stream.

3)      Focus on the improving the inputs to getting better outputs, not the other way around.

4)      Make sure the measures don’t create functional silos.

5)      Create measures that drive and encourage teamwork and problem solving.

6)      Use measurement dashboards that tells a story and promotes dialogue and problem solving.

7)      Don’t filter to make the data look better.

Once you have created a “scoreboard” or measurement tool/dashboard, that document will help show you the current state. Just be sure to continually run through the PDCA cycle with your team and your customer. Share the knowledge to continuously improve and know the score of the game.

Written by Michelle Cribbs, Manager of Lean Supply Chain Operations at LeanCor

This time however, we conducted our weekly reflection meeting in person.   I’d scheduled the meeting in the afternoon as that time is typically smoother for the material planner to discuss improvements.

The focus of this meeting was around a large cluster of suppliers that the engineering team had completed for the material planner’s facility.  The analysis suggested a tweak to their inbound ordering strategy which promotes frequent and stable deliveries utilizing consolidated/milk run shipments.  This proposed analysis projected upwards of $75K annual transportation savings and roughly 17% savings from the transportation spend for that cluster of suppliers.

As I went through the savings opportunities, I began to notice the facial expression of the material planner change to defensive.  Thinking it was probably a good time to get her feedback, I asked, “What do you think?  Is this possible?”

Her response (as expected) was:  “No, and here’s why.”   Basically, we got into a 15-minute conversation about the potential roadblocks.  Everything from “I don’t trust the supplier’s ability to adhere to the plan” to “this is too much work on my end” and even “The MRP system is cumbersome and would be manual in creating a plan similar to what you are suggesting.”

Understanding what the planner was getting to, I guided the conversation and focused on what problem we were aiming to solve for the customer.  To level set again, I asked the planner, “What problem are we here to solve?”  I answered my own question: “We want to consolidate suppliers X, Y and Z every week –  preferably on this day to reap the most in transportation savings. The goal is to potentially save $75K annually and reach the inventory reduction goal that your manager has challenged you to achieve.”

Feeling I had redirected the planner’s focus back to continuous improvement, I asked, “If we take out the systems aspect of it, I’m assuming that systems are the only roadblock since the business process is cumbersome and manual. What do you suggest?”

That key question turned the course of the meeting in a positive way.  While reflecting upon the positives of the proposed analysis, I engaged the planner to take out the “obstacles.” This enabled her to brainstorm how we can get there in a different way, or else set up an action plan to resolve those concerns.

I used some key pointers from PEOPLE: A leader’s day-to-day guide to building, managing & sustaining lean organizations. The book explains how to use reflection for engagement by:

1)      Building reflection into daily, weekly, monthly, and annual PDCA processes.

…It starts with standard work on my part, but even the planners are seeing the value now of weekly reflections.  Hopefully I can keep the momentum going.

2)      Using reflection for learning, problem solving, and driving continuous improvement.

3)      Using reflection to enable cross-functional collaboration.

…For both of the above, by engaging the planner, it set us up to cross collaborate and to problem solve.  More importantly, the individual will feel like he/she is part of the solution to a problem – rather than on the receiving end of a plan they didn’t quite believe in or commit to.  Through that practice of engagement and being collaborative in solving the problem, the planner also learned a lot more on how to approach problem solving in the future.

4. Use reflection to better understand the dynamics of your business.

By removing the hurdles, in those 15 minutes the planner had literally provided all the “rocks” that could be resolved in future projects.  Those will be a part of future reflection meetings.

5. Reflect to create stories for mentoring young leaders.

 I hope that after reading about my experience, more young lean leaders can use reflection in day-to-day tasks; both personally and professionally.

Written by Vimal Patel, Manager of Lean Supply Chain Operations at LeanCor

As my facility team picked up speed it began to feel like my New Year’s resolution to work out at the gym five times a week.  Only this time, I didn’t have the option to be lazy and neglect my commitment.  The facility was up and running 24/7 whether I liked it or not.  Soon I learned to ECHO lean: Educate the Gemba, Chase the plan, Hammer the problems, and Optimize over time.

Educate the Gemba

Education will put the plan into motion and help sustain it later.  Education lays the foundation.  As with my workout plan, going to the gym wouldn’t be enough.  I had to learn how to use the machines and how each would benefit my body.  The facility implementation had to begin with training – teaching what we were there to accomplish.  It was more than just getting everyone on the same sheet of music, it was getting everyone to create the same song.

In Japanese, Gembameans “the real place.”  In order to fully understand the plan, we need to go where it will all take place.

Originally the receiving process was done with one clerk, one printer, and one computer.  When the facility opened, the docks and space available expanded.  It seemed we would be fine using the same amount of processing equipment.  Soon we found that traffic through the docks increased and we didn’t have enough time to verify the freight.  We needed more equipment. This realization could only have been had by seeing the work being done in real time as opposed to hearing about it from team members on the floor.

Chase the Plan

Chase the plan.  For me, this is about keeping focused and keeping it simple.  Trying to over-complicate an  implementation or changing it too frequently only causes trouble in its sustainability.  Get rid of all the ‘good’ ideas and only work with the great ones.  It was difficult for our team members to let go of some improvement ideas in order to stay focused on the plan – the big picture.

Hammer the Problems

Being proactive in a start-up is crucial.  Start planning for potential problems and coming up with contingency plans.  ”No problem is a problem.”  Implementation rides highly on the premise that most of the big problems will be  uncovered first.  Our facility hammered out a big one.  Though we had a shuttle service for manufacturing parts being transferred, we had to plan for “hot” needs that came in by having our own equipment ready to run beyond the scheduled shuttle.

Optimize  Over Time

It takes time to improve and sustain that improvement.  Time will show more problems, better solutions, and ultimately success.  Although our facility is still young, we can gauge where we have been, where we are, and where we are going.  It’s exciting to know there is so much more to learn.

Lean thinking is easy.  It’s the lean doing that is difficult.  I hope the ECHO principle can help you in your own facility start-up.

Written by Tabitha Zamarripa, Lean Fulfillment Center Supervisor 

Image via Wikipedia

“Failure is the opportunity to begin again, this time more intelligently”

– Henry Ford

Being that I’m a LeanCor onsite at a major manufacturing customer, it’s necessary that I need to be a pretty punctual guy.  Give me a project to complete, and I’ll have an outline put together by this afternoon, a first revision done by the next day, and a presentable conclusion in a week.  Needs to include some Excel charts, maybe a pivot table or two?  No problem.

Want some PowerPoint flavor?  I can drop and add objects with the best of them.

But I uncovered a unique problem about a month ago that taxed my ability to do the above things.  It wasn’t the lack of usable data to populate my summary.  It wasn’t even a computer issue that I could blame IT on.  It was simply the fact that I was required to use a piece of software that I had very little experience with, and quite frankly, a little hesitation due to the fact I would need to to coach myself on its use without any assistance from an experienced user.

Also, I almost forgot to mention, I realized that I had the above problems after volunteering to complete this rather complicated analysis.  And I also agreed to have it done by a specific date in the not too distant future.

To describe how this happened, I need to explain my standard process of completing these assignments, which has been successful for me over the last several years:

• Identify the problem
• Document the process that is expected to be needed to solve the problem
• Assemble the needed inputs
• Execute the process
• Evaluate and refine the output into a presentable format

So after taking some time to clearly articulate the need to myself, I sat down to draw out the process on a whiteboard.  Everything was going very well until I found the need to compare and exclude certain records in separate Excel databases that were both of considerable (several thousand lines) size.  It may have been because of a trip I took to observe our engineering department earlier in the year, but regardless of the reason I decided to take a leap of faith and give it a go using Microsoft Access.  I’d always wanted to learn the tool given my proficiency and knowledge of the limitations of MS Excel, so I bought an Access book that had a lot of great reviews and decided to sit down one night to pickup on the finer points of the program.

Unfortunately, that book was about three inches thick, and because of that I was unable to glean the knowledge.  I tried sifting through to find the specific sections that would give me the information necessary to put together my analysis, but due to the multiple variables and associations in the database, there was just not enough time to look into every topic and then try to figure out how they all related to each other.  Strike one.

Figuring that I’d exhausted the time that I had available to allocate to book research, I turned to my next best source of Access knowledge – a friend that owed me a favor.  We went out, grabbed a bite to eat, had a couple of beverages, and started on the task of loading my tables into a new Access workbook out of an Excel database.  Unfortunately, once we got past the point of loading all of the pertinent information, I found out that we had exhausted the limits of his expertise, and I was on my own again.  Strike two.

At this time I was feeling more and more resentful of Microsoft in general and Access in particular.  Nonetheless, I gritted my teeth and cleared my calendar, determined to make the program work by blunt force if nothing else.

I sat for hours trying to navigate tables, queries, associations, and the all too common error message.  I was getting nowhere fast, and my frustration began to build with every keystroke.  Finally, I gave up, called it quits, and called the guy that I promised to show the final results to.

The conversation went something like this:

John – I can’t finish this, I don’t understand Access.

Jake – Where are you at with it?

John – I’ve been trying to create this association, I’ve done it, but I can’t export it to Excel.  If I can’t do that, then how can I possibly finish the rest of the project in Access?

Jake – Why don’t you copy your result and paste it into Excel?  The comparison is all that you needed access for, do the rest of the project in a program you’re comfortable with.

John – …

Jake – John?

John – (Bangs head on desk)

Jake – Hello?

John – (wincing with the pain of someone who missed the obvious) – Yes.  That should work.  I’m going to go sulk in a corner while finishing this project up and will have it to you in the morning.

And sure enough, the next day I changed direction, put the revised information back into my pet program, and had the analysis complete within a couple of hours.

Looking back over the past couple of days to evaluate where I went wrong, I realized that I had a fatal flaw to m

y approach – the inability to recognize that I could revise the plan that I had initially put together.   I was assuming that I would need to do the entire project in Access, when in reality all that was needed was a basic query result that could be exported into a familiar program.  Deep immersion into Access could wait for another day, at a measured pace.

The moral of the story is that sometimes even the best laid plans need to be audited for efficiency.  At the moment that I got stuck I should have evaluated the time that I had remaining to finish the project, the expected complexity of the original plan, and any other alternatives to achieving my goal.  Instead, I wasted countless hours on a fruitless exercise, only to go back to the program that I should have been using in the first place.

While I will continue to use the same 5 steps listed above in order to take on new challenges, there will have to be awareness that sometimes the prepared plans for a task can’t be finished in the time allotted.  Similar to pulling an andon in a manufacturing center to avoid passing on a defect, these cases involve stepping back to find the root cause of a problem, analyzing for inefficiencies, taking time for correction, and finally finishing the task by producing a product that meets or exceeds expectations –

utilizing one of several other methods not previously considered.

Written by John Szoke, Lean Logistics Manager at LeanCor

A bit of background: Tend to work on enterprise software which in my case usually means a very heavy leaning on web services and a service oriented architecture (SOA). With this architecture comes a need to transfer, read and persist structured data. For a long time I have relied on SOAP as a the de facto standard but you know what? SOAP is terrible. It’s inefficient, hard to generate and hard to parse or deserialize but the biggest gripe I have with SOAP is how bloated it is.

Take the following example – all it does is return the message “Hello from soap”.

<?xml version="1.0" encoding="UTF-8"?>
<string xmlns="http://tempuri.org/">Hello from soap.</string>

A nice round 100 characters including spaces – a little excessive in my book! We need a better solution.

Cometh the hour, cometh the JSON.

JSON or JavaScript Object Notation is a notation for Javascript objects. OK, that wasn’t very clear, let me try again. JSON is a data interchange format typically used for serializing and deserialising javascript object trees. Simplified this is a way of representing objects such that they can be transferred or stored the converted back into the original objects later.

You might think of JSON as an alternative to XML.

Take a look at the exmaple below, it represents a collection of people:

{"people":{"person":[{"name":"Dave"},{"name":"Mark"},{"name":"Jane"}]}}

The equivalent XML to our JSON string would be:

<people>
    <person name="Dave"/>
    <person name="Mark"/>
    <person name="Jane"/>
</people>

If we ignore the setup overhead and actual names, per person in the collection, XML requires a staggering 54.5% more characters than JSON ({"name":""} (11) vs <person name=""/> (17)). Scale this up too a few hundred thousand rows (not uncommon for some of the projects I work on) and this quickly becomes a big concern.

JSON can provide us with a significant saving.

Practice

Take a look at the very basic web service below. All it is required to do is return a collection of Person objects when GetPeople is called.

public class Person
{
    public string Name { get; set; }

    protected internal Person() { }
}

[WebService]
[ScriptService] // This is important.
public class PeopleWebService : WebService
{
    List<Person> people;

    [WebMethod]
    public List<Person> GetPeople()
    {
        if (people == null)
        {
            people = new List<Person>();
        }

        people.Add(new Person() { Name = "Dave" });
        people.Add(new Person() { Name = "Mark" });
        people.Add(new Person() { Name = "Jane" });

        return people;
    }
}

We will invoke GetPeople with the following jQuery script:

$(document).ready(function () {
    $.ajax({
        type: "POST",
        url: "PeopleWebService.asmx/GetPeople"
    });
});

What this script does is creates an asynchronous POST request to our web service. Using Fiddler or another similar packet inspector, we can see the result of the script is:

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfPerson xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance
" xmlns:xsd="
http://www.w3.org/2001/XMLSchema
" xmlns="
http://tempuri.org/
">
    <Person>
        <Name>Dave</Name>
    </Person>
    <Person>    
        <Name>Mark</Name>  
    </Person>  
    <Person>    
        <Name>Jane</Name>  
    </Person>
</ArrayOfPerson>

This is similar to the bloated mess we saw in the Hello World example earlier. There is a lot of information that means nothing in our context as well as it being overly verbose.

A little known gem is that this web service already has everything in place to be able to return JSON to the client. All we need to do is invoke the method slightly differently. This is the same script as before with a little extra definition information:

$(document).ready(function () {
    $.ajax({
        type: "POST",
        url: "http://localhost:32872/PeopleWebService.asmx/GetPeople",
        contentType: "application/json; charset=utf-8",
        dataType: "json"
    });
});

The addition of the contentType and dataType variables tell ASP.NET what format I want my results in (an also my inputs but we wont go into that today). The change is profound:

{"d":[{"Name":"Dave"},{"Name":"Mark"},{"Name":"Jane"}]}

Not bad at all, in fact better than the original example.The xml result is 322 characters including spacing and the JSON result? A measly 55 characters. The XML result is 485.5% larger!

While i grant you, the xml could be minified and serialised better, scrictly looking at the out of the box version, the saving cannot be ignored.

“I am only half way through the series and I am already able to apply the principals and tools I have learned back at my company.”

There’s no doubt the Lean Supply Chain Certificate Program is providing real results. Click below to hear what else participants are saying:

Missed the Lean Supply Chain Webinar on February 3rd?

Watch it here.

Discount Code:

The Supply Chain and Logistics Intitute is also offering you a special $250 discount off your registration for one of the 2012 Spring Lean Supply Chain courses or sign up for the whole series for $6,000 (you save $1,200!) Please use the promotion code “LEANWEB” to receive the special discount. Register online or call 404.385.3501.

Lean Supply Chain Certificate Courses:

To become a Lean Supply Chain Professional, we must grow our skills in three areas: Lean Problem Solving, Lean Supply Chain Application, and Lean Leadership.

In this free one-hour webinar now available online, you will be introduced to:

• Lean problem solving through the use of problem solving tools to eliminate waste at the root cause

• Connecting lean to supply chain management, discussing how concepts such as pull and one piece flow will lead to reductions in total cost of the supply chain

• Transforming an organization from traditional to lean thinking with lean leadership

Robert and Kevin cover these areas and explain how each plays a critical role in creating a lean supply chain. The aim is to reduce the total cost of the supply chain – removing waste and creating the most value for the customer.

Be a Better Developer

Being on the software development side of LeanCor, it is important to have structure to your code.  Something that we as developers do to maintain our code is practice DRY.  DRY simply means “Don’t Repeat Yourself.”  Rushing is a common problem that can occur when balancing emergencies and standard projects.  It’s much easier to copy and paste a function, manipulate it, and push it out.  By doing this however, you create the opportunity for errors in the code later when you have to manipulate both of the functions.  It’s very possible that a developer won’t know of or will miss one of the functions that need altered now, thus creating emergencies.

Refactor Your Code

How does one overcome this problem?  Find commonalities in the code, and re-factor it.  Take the functions that are similar and if possible, break them into several smaller functions.  Maybe make a call to one main function that calls all those several smaller ones from multiple locations.  This allows you the ability to keep your code dealing with a specific functionality all in one area.

While coding if you find yourself asking, “What is the next step to accomplish the goal?”  You should probably break that next step out into it’s own function.   What this allows is the code to be very modularized and any errors that occur are much easier to find and correct.

Use Long Function and Variable Names

Another major step in making life as a coder easier is long function names and variable names.  This allows commenting your code without actually commenting your code.  Why is this good?  It reduces the file size, everything you need to reference is right in front of you, and most importantly the programmers don’t need to maintain the documentation -  the code is doing that itself!

Clean Up Old Issues

What if you find poor coding practices from others around the area you’re coding?  We have a saying in our IT department: “Leave the campground cleaner than you found it.”  Go ahead and fix it.  It solves future headaches and cleans up the code for when others have to “camp” there.

Not having always been a believer in some of these methodologies, I’ve challenged myself both in practice at home and at work.  I’ve found myself not having nearly as many problems in logic or frustrations.

Recap

So let’s recap.  Structure is vital to having functioning code.  Practicing DRY will prevent future issues from occurring because you don’t have to manipulate multiple locations.  Refactoring your code allows the programmer to travel easier through the code and find errors quicker as functions are much smaller. Think about each step and its own individual function.  Create long function and variables names.  Who needs comments now?!  If you see something that appears to be rushed or was poorly coded, fix it now.

Written by Roman DeNu, Software Development Specialist at LeanCor

Related articles

• Key paradoxes in agile (softwaretrading.co.uk)
• .NET Framework Gives Splendid Set of Object Class Libraries Incorporated into its CLR (jamescatalano.typepad.com)
• Maslow’s Hierarchy of Needs of Software Development (hanselman.com)
• Massive-scale Online Software Development (whathecode.wordpress.com)

Daddy and stepmummy are very poor, so stepmummy tells daddy to dump children (Hansel & Gretel) in the woods to die. First time, children overhear the conversation, prepare themselves and leave a trail of white pebbles on the way to the forest. After being left, they retrace the pebbles and return home safely, much to the delight of daddy. Second time however, no preparation takes place. Hansel is left with breadcrumbs as a crappy alternative to pebbles. Conclusion: they get lost, run into the witch and nasty stuff happens (All ends well, but that’s not the point of this post).

Allegory time.

A B2B Salesman or -woman is very much a Hansel or Gretel. A great sales visit is all about preparation, structural empathy (i.e. a well thought out process), and retention of key data. To the desperation of B2B sales managers everywhere, more often than not, the breadcrumb trail is the path of “choice”. Qualification, needs analysis and proposal tend to be based on experience and inspiration of the moment, rather then the process laid down by the company, resulting in volatile hit rates. Moreover, relevant prospect data, if collected, fails to find its way into CRM.

Not only does this approach endanger current sales, the lack of data transfer robs both the sales and the marketing organization of actionable insights, leading to extra costs and a diminished number of qualitative future leads.

But why? Why is it so hard to follow processes and to retain data? In conversations we had with sales professionals, CRM came out as an important scapegoat. While most systems are very broad and complete, it is the lack of speed and usability for the sales rep that creates a barrier. As a general rule, sales professionals focus their daytime on moving from customer to customer, and when a tired rep comes home, mustering the force to put in the last round of quotations, most of the data breadcrumbs have been eaten…

Do you feel the same pain? How does you CRM system cope with this reality?

We don’t really do TDD, we are a long way from achieving continuous delivery and our low levels of test coverage make releases a nervous time, but we think we’re pretty good at Agile.

I was reflecting on what I had learnt in the past year and how agile my team had become.  Despite immaturity at some of the key agile practices, in 12 months we deployed 79 releases to production for an application that is now processing 2 million transactions a day and serving 5 lines of business, 45 products and 3,000 concurrent users.   We ran four major projects concurrently while supporting production on a single codebase.  2011 involved lots of hard work, a dose of good luck and some progress on our journey to be more agile.

So here are some things I learnt last year:

1. Speed.  Velocity is great, especially if you deploy to production often, because business benefits start rolling early.  Rapid delivery also builds confidence and trust in your delivery capability (with management and the business).  There is, however, a dark side.  Velocity for us has brought with it technical debt.  The business and project teams care less about this while projects are delivering but speak to any production support or maintenance team and quality and technical debt usually feature highly.  Getting the balance right is difficult.  Do you pay your credit card off every month or let the interest grow till you hit the card limit (there’s a reason banks set limits on credit cards – there’s a point of no return).  Lesson –Deliver things fast to build business trust and confidence – success breeds success.  Make sure someone champions quality and technical debt reduction.  Velocity rarely needs a champion because it’s simpler to understand gets its own momentum.
2. Quality.  If speed is not matched with repeatable testing capability then you’ve built technical debt because every change requires regression testing to give confidence that the production system won’t break.  Remember this is the same functionality we wanted to deliver fast to get early benefits – if changes break the system your benefits stop rolling a lot faster than your project took to get them rolling.  Building quality in is the best way of working.  Traditional projects have late testing cycles.  The culture of ‘develop functionality fast and get someone else to test it later’ (lets call it test separation) amplifies two problems.  The first is slow defect feedback cycles which raise costs and lowers quality.  Secondly, projects cut testing effort when schedules slip and deadlines are committed.  Test separation culture is strong and difficult to shift to a team owned test culture (BDD, ATDD, TDD, test automation ie team shared accountability for building quality in).  Don’t underestimate this.  This is particularly important as you scale.  A team of 8-10 TDD guns can do amazing things, but when you scale that to 150, you have different problems to solve (hiring 10 TDD guns won’t change the other 140 people).  Lesson – Invest in building quality in.  It’s cheaper and more effective long term.  For larger teams you need to build capability and apply change management to make it stick.
3. Scale.  Size matters.  Agile is easier with small teams of smart engaged people but so is waterfall.  Big organisations have momentum and it’s difficult to turn a big ship.  Beware lipstick on a pig (politics drives some people to put lipstick on their pigs and call them agile) – thankfully agile is pretty transparent and pigs with lipstick stand out if you’re willing to walk the floors and read a few story walls.  Scaling from 10 people to 100+ usually means you have a normal distribution curve of capability.  To counteract this you need a change program at multiple levels.  Examples include the shift from manual to automated testing and the changing role of BA’s, developers, testers but also decision making and business involvement.  Lesson – Walk the floors, use the transparency to reinforce the changes.  Be brave enough to declare pigs with lipstick as pigs.
4. Culture.  From a leadership perspective this is one of the most important.  Many people see Agile as a methodology or see technical views of practices like TDD.  From a leadership perspective I see a shift from hierarchical command and control to self empowered teams – the teams choose what stories get done next.  This is confronting to leaders who thrive on the power of control and followers who want to be told what to do.  But a culture where people collaborate to understand business priorities and work together to deliver them faster is very powerful.  Cultural change needs strong leadership but also needs the right attitude and adaptability of the people in the engine room.  Lesson – Be willing to try new things and make it safe to fail.  Educate business, technical leaders and project managers as well as the engine room.  Set expectations – not everyone will drink the kool-aid.
5. People.  Standups and retrospectives are easy to learn, TDD is hard (as is BDD).  Many TDD advocates probably disagree, but I’ve found this practice to be much more difficult to adopt at a large scale.  I think this is because it’s a mindset shift.  Arrogance plays a part but change resistance is a bigger component.  Why do I need to test a one line change to a 10 line class?  In an application with 500,000 lines of code no one knows how the whole thing behaves.  TDD combined with automated acceptance tests provides fast feedback (read higher quality and lower cost defect reduction) and confidence that changes can be deployed to production.  People who have relied on testers and testing stages of projects for years struggle to change to the mindset that testing happens at the beginning, should be automated and repeatable and is the whole teams accountability.  Lesson – people naturally resist change.  A learning culture still needs goals and measures to help guide and drive capability improvement.

In summary, do simpler agile practices first, build on successes, keep learning.  Some agile practices are hard (especially at larger scale) but also have greater benefits.  Build a learning culture.  To misquote a Zen saying, if you think you’ve achieved it, you haven’t.