It’s Time for a Non-Stop Flight to Efficiency
Grounded in how it’s always been done while continuing to live on razor-thin margins?
Perhaps it is time to take a chapter out of the airline industry’s book of survival and profitability.
Sitting on the tarmac of Denver International, I reflect for a moment and begin to quantify the amount of changes I’ve endured as a top-tier frequent flyer the last twenty years (most obviously, gone are the days of blankets, pillows and peanuts). Subtly here to stay is a culture of continuous change for the airlines that carefully balances increased consumer satisfaction while driving operating costs down.
During the last twenty years, the airline industry has successfully adopted and deployed paperless tickets, on-line check in, self-service kiosks, and texting customers to provide flight updates and gate changes. Less successful has been shifting from cloth seats to some unrefined and uncomfortable blend of plastic and leather while slowly changing seat backs from solid pockets to nets (where my ear buds are continually snagged). So why all the changes? The airline industry is simply leveraging all aspects of technology and process reengineering to reduce operating expenses. The airline industry has effectively reduced cleaning times for planes to increase on-time departure rates. They have trimmed call center volumes and customer complaints while successfully driving a self-service customer model, a self-service freedom that fliers like myself embrace as it helps off-set other cost-saving features that are often difficult to digest. For instance, smaller seats and lower arm rests or having to fly a small and cramped regional jet for flights over two hours (a plane historically reserved for shorter flights). Not to mention the highly publicized baggage fees. While baggage fees are painful, it’s genius if a company wants to force consumers to reengineer packing habits in order to help reduce baggage load time and employee disability claims.
These gains in efficiency have certainly come with some trial and error risk, such as the famed boarding of window seats first and then aisle, but risks were taken and ROI was eventually achieved with the projects that succeeded. Simply said, the airline industry lives in a perpetual state of change. Change is never easy for either employees or customers, however it is ultimately required to ensure the long-term success of any organization. The airline industry has successfully adopted a culture of continual improvement that strikes a careful balance between convenience and inconvenience in order to lower operating expenses while increasing customer satisfaction.
In order to develop a culture of continual process improvement, organizations first have to take a ‘philosophical’ stance that this is the direction they will be moving in. Second, the organization needs to design and implement a ‘strategy’ to achieve and maintain a culture of continuous process improvement. Finally, it’s all about ‘execution’. My dad always told me that nothing is worth thinking, complaining or talking about unless you’re going to do something about it. Carefully plot out and define what improvements in process, technology or tools will be implemented year over year to achieve increased customer satisfaction, lower operating expenses while potentially risking a little customer inconvenience. Now execute!
In today’s new banking reality, a commitment to increasing productivity, service and profitability while reducing cost will be imperative to a firm reaching its destination of long-term success. Does your organization need to take a hard look at itself and ask if it is truly paperless or allows customers to boldly self-serve? Is the organization providing tools or changes in process that require consumers to reengineer the way they operate in order to help lower costs and reduce disability claims? What perpetual state is your organization living in? More poignantly, what is your organization going to do to develop and drive a culture of continuous change and improvement? Is your organization ready to take the bold step and board a non-stop flight to efficiency and ongoing process improvement?
In a previous blog, “The Reality of T.E.A.M”, I talked about Agile teams being dedicated, or part of a ‘permanent’ team that focuses on a single solution and remains together over time. Another big factor of an Agile team is that they are cross-functional in nature.
What is a Cross Functional Team?
When the topic of cross-functional teams comes up, there seems to be varying opinions that come out. What does it mean when I refer to teams being cross-functional? Does everyone on the team have to be able to do every job? Do all team members have to know every detail of everything that goes on inside the team? Does the team have to ensure that they can complete their solution? Let’s look at what cross-functional means for Agile teams that I work with.
If you want to define it, you will most likely find that it means something like “a group of people with different functional specialties or multidisciplinary skills, responsible for carrying out all phases of a program or project from start to finish.”[1] If you stick with this definition, you may find that you do not have to have a team where everyone on the team knows how to do every job on a team, but more that it is meant to keep members focused more on their role in moving the product forward than on their title.
Now that you’re on a Cross Functional Team
When the members of a team hear they are to be cross-functional, I’ve seen them get a little uneasy thinking they have to become something they may not want to be or learn to do things they don’t want to do. I call this their ‘mini identity crisis’ because these team members are so centered around their title defining what they are supposed to do, they lose sight of what it means to be a team.
Team members will hopefully come to understand that becoming part of a cross-functional team means they will be focusing more on their role as a team member than on what their title is on their HR file. Being a cross-functional team member is about ensuring you chip in whenever necessary and do as much as you can to ensure the solution is complete, and as good and valuable as it can be.
It’s not necessarily important that all team members know how to do everything, but it is important they work together, embracing common Agile principles from the Agile Manifesto and Principles, as well as principles that are found in Agile methods, such as “’Collective Code Ownership’ in Extreme Programming, which ensures the entire team owns the code and ‘Self-Organization’ in Scrum, where the team organizes themselves to get the job done.
Where does an Agile Coach fit in?
When coaching cross functional teams, I try to support and help them understand they won’t be losing their identity, but they are going to become part of a larger solution. I emphasize that they’re not ‘against each other’, or ‘apart from each other’, but ‘for each other’. I’ve found it’s important for team members to communicate and collaborate so they feel like part of a team instead of a pool of resources thrown together and asked to feel and behave like a team.
For all you sports fans—A Sports Analogy
Cross-functional teams remind me of football teams. In football, there are multiple positions, both on the offense and on the defense. While each member of a football team is most likely drafted onto the team to play a specific position, such as protecting the quarterback, the skills they possess for that position may also translate to other positions on the team. For example, the player that protects the quarterback can use those same skills to get around the protection of the other team’s quarterback and sack him. Just like a football team has players who are able to move to different positions in order to win the game, Agile teams use the same idea to produce the best possible solution!
I like to attempt minor DIY projects around the house because 1) it saves money and, 2) it’s enjoyable to solve technical issues that don’t involve staring at a computer. Recently, I decided to wire the living room with recessed lights. There is no existing light fixture in the ceiling so I had to use power from a receptacle and wire in a new switch to control the lights.
I didn’t want to cut through the wall board, run wire and then find out that I didn’t know how to actually wire into the receptacle. So, I decided to approach the problem much like I do when faced with a daunting programming problem – by unit testing.
I pulled out the receptacle, examined the wiring, and scratched out a plan on a piece of paper. Then I wired a light switch and cheap single bulb fixture off of the receptacle. Luckily, it worked without major adjustments or shocks. And it entertained the kids for about 3 minutes.
I then was able to confidently cut through the wall and wire in the switch, solving one piece of the puzzle and allowing me to focus on installing the overhead lights.
As a design technique, Test-Driven Development (TDD) allows us to break down complex systems into smaller, more manageable chunks. Once you’ve written tests to satisfy a cohesive set of requirements, you commit the code and move on to the next set.
A good example of this can be found in the book, Practices of an Agile Developer (Subramaniam, Hunt). One of the practices is described as Attacking Problems in Isolation. As the authors explain:
“Large systems are complicated – many factors are involved in the way they execute. While working with the entire system, it’s hard to separate the details that have an effect on your particular problem from the ones that don’t.”
Isolating the problem is also useful when debugging a system issue that is buried under layers of UI, database and middle-tier abstractions. Remove each layer until you’ve discovered the likely culprit. Or build a simple prototype and isolate the misbehaving module.
It’s easy to get overwhelmed by a complex system when trying to decide where to begin. It may feel like a house-of-cards, teetering on the verge of collapse with the next interruption. Consider TDD as not just a test fixture, but as a design technique that helps narrow the scope.
And as for wiring a home – keep it simple and remember to cut off the power.
Agencies around the government are beginning to see more and more of their employees teleworking and going to modified work weeks. There are a number of employees that work enough so that they can modify their schedules to be off every other Friday or Monday, or even every Friday or Monday. Due to a number of factors, many employees are also teleworking, or working from home. Sound like you or someone you know?
What does this have to do with Agile?
I hear very often that one of the most talked about, and even controversial, things about an Agile transformation is the idea that teams must all be in the same room in order to satisfy the 6th principle of the Agile Manifesto “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
If we take this principle into account, then we find that the telework and modified schedules turn this upside down and cause some confusion and concern on whether or not an agency can actually transition. I have had a number of federal employees, especially leadership; ask if they can really transition to an Agile culture. The actuality is “yes” – an agency in this situation, can most certainly transition to an Agile environment!
The biggest question for any agency is not “can we?”, but “how do we?”. The agency needs to start with the understanding that the 6th principle says that face-to-face is “the most efficient and effective…” way to communicate; it does NOT say that it is the only way to communicate. It is so very important to encourage face-to-face communication for those that are in the office on a daily basis, but not so important that they relinquish the teleworking or modified schedules.
The key is to have the agency give the teams as much encouragement and support as they can to help create an atmosphere that fosters communication and collaboration in many different ways. The agency will need to enable team members to communicate through means that may not have been ‘the usual’ in the agency. Many government agencies have never had to put a lot of effort into ‘unusual’ modes of communication and collaboration because either the employees have been in the office all the time and/or the employees have worked fairly independently. The more independently employees work, the less they need ways to communicate and collaborate outside of the ‘usual’ means of phone and email.
Agencies that need to step out of the ‘normal modes’ of communication are most likely very skittish of doing so for a multitude of reasons. Some reasons I have been told that agencies may be skeptical is the level of security that needs to be maintained in the agency; most agencies will admit their security levels are much higher than those of private industry. Because of the level of security that needs to be supported, many obvious communication mechanisms are overlooked or pushed aside without fully investigating the overall options.
However, in today’s technological age, there are many options that are available. Any agency that is looking to transition to a more collaborative environment, one in which Agile can flourish, needs to look beyond names and find what works. They should start by understanding the needs of the teams and work with the teams to find solutions, such as Office365, webcams, bridgelines, etc.
The one thing that agencies should never assume is that they cannot transition to an Agile environment simply due to these modified schedules or teleworking situations. It all comes down to support and encouragement of teams made of people that are not all sitting in the same location…something that many agencies have not had to deal with before now!
Have you been in this situation? Do you know some that are? What do you, or they, think can be done to be more collaborative?
Being always busy does not always mean being productive
As often happens at the end of a calendar year, many people reflect on the past and start thinking about what would make sense to do different in the future.
Recently, I was having such a contemplative conversation with a client. He asked me if I am seeing any trends with management practices that, while put in place with good intentions, have unexpected consequences or side effects. He wanted to understand if his organization’s challenges in meeting delivery date commitments and accelerating time to market are rooted more in something they do versus something they don’t do.
Utilization Vs Throughput
While there are many trends I could talk about, there is a common pattern I have seen not only in the past year, but for the past twenty years. This pattern is prevalent in silo organizations and is usually a result of good managers doing what they are expected to do: keep systems running and control or minimize costs, while maintaining organizational commitments. If managers do these things, they are “managing well”.
One way to minimize cost is to minimize waste. What do we consider one of the biggest wastes in our environments? Idle resources. We don’t want idle resources because it feels like we’re wasting money, like we’re paying them “for doing nothing”. So, managers often aim for departmental efficiencies by focusing on maximizing utilization of people in their department. In knowledge work fields like software engineering and information technology, this practice is frequently used to minimize costs within a department.
While controlling personnel costs is managed at the department level (e.g. Product Management, Project Management Office, Development, Test, Operations, Support, etc), maintaining organizational commitments can be achieved only through synchronized efforts across departments.
Although not readily apparent, this creates a conflict because the organization’s throughput is deeply affected by the flow of work through the whole system and has nothing to do with local, departmental efficiencies.
Stop Managing Locally, Start Managing Globally
Maximizing resource utilization at the local level does not necessarily support an enterprise or systemic (i.e., global) optimization of getting products or services to market as quickly as possible. Quite often there will be departments with minimal slack time because the people are fully utilized, yet they are creating long delays for other departments. While everyone is very busy (and that makes us feel good), projects seem to take forever to be completed, or are completed so late that market opportunities are missed.
As long as we manage a complex production system such as an IT organization by breaking it down into department subsystems, and we manage these subsystems individually, we’ll continue to find it difficult to achieve significant jumps in throughput or profit within a relatively short time (months). The fact that each subsystem is optimized does not mean that the flow through the system is optimum.
Managing departmental costs means making management decisions according to local efficiencies, whereas managing commitments and reducing time to market requires management decisions according to global efficiencies. In other words, to manage, improve, and predict the output of an organization, we must be able to understand and optimize the flow of work through the whole organization and NOT the local efficiency within each department.
A Fundamental Shift
The shift in thinking required to manage globally vs locally is significant for many organizations, and starts with the leadership team.
However, the inability to make this change throughout an organization is a common cause of failure when trying to increase throughput, improve adaptability, and achieve enterprise agility.
As the Recruiting Manager at CC Pace, I am regularly giving advice on how to prepare for an interview. More often than not, it isn’t what a candidate says but what they do or how they present themselves can turn a hiring manager off to a candidate. I came across a great image that illustrates some of the most common nonverbal mistakes made during a job interview. Some surprising statistics are 47% of candidates have little or no knowledge of the company they are meeting with – Wow. If you take one thing away from this, I would recommend that you take the time to do some research on the company and prepare. Enjoy the image and perhaps it will make you think about a few things that can positively impact your interview experience!
Image courtesy of http://www.proresumecenter.com/common-nonverbal-mistakes-made-during-a-job-interview/
During a recent family driving expedition, my teenagers were surprised at a rest stop along I-95 when an attendant began filling our gas tank. “Why is that guy pumping our gas?” After providing the short answer (“New Jersey is a rare state that prohibits consumers from servicing their own vehicles”), I reminisced about “the good old days” when gas station attendants not only filled your tank, but checked the oil level, put air in your tires and washed your windshield—all at no additional cost! “Why would they do that?” “Customer service. That’s how they competed for your business.” Those days really do seem so far away, don’t they?
In the early 1990s I did a project for Richmond, VA-based Crestar Mortgage (pre-SunTrust merger). I was helping to define the business requirements critical to replacing their loan origination software and a question that came up early in the discussions with their executive team was “why don’t mortgage systems interact with the bank’s customer information file?” That was a good question then, as it still is today. Most consumer banking systems are predicated on a customer information file (CIF) to connect all the various banking products and services the customer might use. Consumer banking systems are generally customer centric, thanks to that CIF, which is critical to good customer service and, not coincidentally, cross-selling and retention. Marc Smith, CEO of Crestar Mortgage at the time, promoted customer focus as a key aspect of company culture, so much so that his organizational chart was inverted—his role was at the bottom of an up-side-down pyramid, supporting the management team, who supported the staff, who served the customer. In short, Marc felt that everyone should act as if they worked for the customer.
Mortgage systems, unlike their consumer lending brethren, and for reasons I still cannot understand, are loan-centric by nature. Sure, they deal with borrower and property data, but at their core, they are all about the loan. They deal with the details of this one loan, no matter how many times the property has been bought and sold, how many times this particular borrower has refinanced the same property, or what other banking services they may use. Is it any wonder that customers have such limited sense of loyalty to their lenders or servicers when there is no reciprocation?
It was a great pleasure to be back in the Richmond area a few years ago (nearly twenty years after my Crestar engagement) working with Jeff Coward, SVP of Mortgage Lending at Virginia Credit Union, and his management team on an LOS selection. While defining the business requirements for crafting an RFP for our vendors, Jeff made one thing very clear: “Whatever system we implement has to allow us to pull member information from the CIF into the loan app. They are members; we can’t sit there and ask them to tell us information we should already know.” No commercial system provided that capability out of the box, so Jeff paid dearly for customizations to make it happen. For a state-chartered credit union, customer loyalty—or member loyalty, more accurately—was paramount. Accepting anything short of respecting that relationship was simply out of the question. The real question is why haven’t more lenders pushed their system vendors to do the same?
More recently I’ve been working with the Export-Import Bank of the United States to help find opportunities for making business processes more effective. Improving the customer experience is one of Ex-Im Bank’s strategic goals, so we are continually looking for opportunities to improve both process efficiency and customer experience. Ex-Im Bank takes this goal seriously, so much so that they have a Vice President of Customer Experience, Stephanie Thum, who I often have the pleasure of working with. Stephanie’s efforts include significant amounts of customer interaction, directly and through focus groups, to gather input on their experiences in working with Ex-Im Bank, their impressions on the levels of effort required to transact with the Bank, and ideas they have for making the process a better one.
Creating a senior management role focused directly on the customer and the experience they have with doing business with your organization is a very powerful statement, and an effective means to measure your success in meeting your customers’ expectations. More companies need to take that step like Ex-Im Bank, insist that technology systems support the customer relationship like Virginia Credit Union, or simply challenge conventional modes of operation by the symbolic gesture of inverting the org chart like Crestar.
Sometimes we should just wash a few windshields. It could serve to remind us who we really work for.
Have you ever wanted to learn a new sport? Cricket, Golf or Rugby?
Where would you start? You may say, well I would find a coach. Maybe, you would consider reading a book, or watching a video, i.e. training!
So You want to learn a New Skill
Let’s use golf as an example.
If you’ve never seen a set of golf clubs, reviewed the rules of play, or know what a golf course really looks like, how will you learn to play? If you haven’t had any training, and you hire a coach, they will give you training. Coaches can’t help you improve your game until you understand the basics. If you’ve had training, a coach can help you incorporate what you’ve learned and give you pointers to help your game.
Training Lays the Foundation
Let’s introduce you to the course. It is played over 9 or 18 holes (sprints). The goal is to have the lowest number of swings possible (inverse velocity) while trying to get the golf ball from the tee into the hole. Holes differ from par 3’s to par 5’s. To move the ball from the tee to the hole, clubs are used. Clubs are grouped together by their primary use. There are drivers, irons, wedges, and putters. Once you’ve been trained on the basics of maneuvering through the course and using clubs, you can get out on the course. You practice, and practice, but your score is not what you want. You need “continuous improvement” to improve your score. This is where coaching comes in.
As Agile trainers, we like to get to know your organization. What are your goals and objectives of training? Are we introducing something new to your teams? Through learning about your organization, we can tailor our training specifically to your teams. Trainers can better provide a pragmatic approach by learning the big picture (how big and what type of golf course are we working with). Spend a little time up front with trainers to determine exactly what your needs are. Then rather than having them provide “out-of-the-box” or “by-the-book” training, you will get a customized approach that enables your teams to get the most out of training. Your teams will be introduced to Agile (the big golf course), its various roles (clubs) and ceremonies (swings). Together the organization will engage on a journey to establish best practices to enable organizational success through Agile methods.
Coaching Helps You Improve
Coaches look at what you are doing. Do you have the right clubs? Are you selecting the right course for your play? Are you holding the clubs correctly? Coaches can help make sure you do not fall into bad habits. They can also help you to avoid or get out of sand traps. Coaches point out if you’re lifting your head during a swing, if your feet are positioned too close together, or if you are using the wrong club. They give you suggestions to try, and let you practice a bit more. If you don’t take any of their “suggestions”, improvement may only come from you working harder and harder to get to the hole. If you take their suggestions, your score will undoubtedly improve. In fact, the objective is to show continuous improvement. A golf coach may not only watch your swings at a range, but may play a few rounds with you. This helps them see the big picture of your play rather than just how you approach a par 3, specific lie or a long put. If gaps in your knowledge appear during full play, a coach may have to act as a trainer or suggest training.
As Agile coaches begin an engagement, they often want to assess where everyone is at in their use of their chosen Agile method. How much training has the team/organization participated in? How is practice going? Coaches do this by observing, asking questions, and participating with teams throughout a given time period. Within Scrum, a coach will follow you through sprints. Within the sprints, Scrum has many ceremonies to navigate where a coach’s impact can be seen. Observing how the team works together, and how well the team executes each ceremony allows a coach to provide feedback for improvement. An Agile coach may encourage the team to step out of their comfort zone trying something new. They may suggest teams engage roles a bit differently both inside the team and across other parts of the organization. A coach can help you review your results, and pick something to improve each iteration. Coaches work with specific individuals on improvements they can make, as well as working with the team as a whole. Some basics outputs of coaching will likely include:
- Establishing a cadence
- Standardizing Agendas for Scrum Ceremonies
- Clarifying roles, and helping team members perform within those roles
- Identifying and improving your velocity
- Establishing an environment for continuous improvement
Use Both to be Your Best
Just as in golf, where training and coaching gives you the foundations for play and then helps you reduce your overall score, Agile training and coaching gives you the foundations for Agile and then helps you increase your velocity. So invite your trainers and coaches on your journey to improving your Agile game. Your organization will thank you with more frequent delivery of working software.
Do you ever wonder what recruiters think when they receive and review your resume? At CC Pace we receive thousands of resumes each year. Some candidates apply online to our current job postings, while others are referred to us by employees, family members, and friends. Regardless of how we receive your resume, like most companies, it is added to our applicant tracking database that holds more than 50,000 resumes. So, how do you make your resume stand out when you’re applying for positions? How do you differentiate yourself in a competitive job market? What are recruiters really thinking when they review your resume? Below are some tips compiled from About.com’s Allison Doyle that may help you fine-tune your resume and assist you in making some impactful changes. Best of luck with your job search!
10 Seconds and Counting:
Recruiters spend an average of 10 seconds reviewing each resume, so you’ll want yours to be…
1) Concise (You only have 10 seconds)
2) Structured (You only have 10 seconds)
3) Specific (You guessed it… 10 seconds)
Brian Shoicket, Dean of University & Community Partnerships at Wakefield Media
Add a Link:
Sometimes the hiring manager or HR representative may not be familiar with your former company. I suggest adding a hyperlink to the company in the Experience section of your resume. Consistency is key though and a hyperlink should be added for each company listed on your resume. Doing this quickly allows the decision maker to review a company’s products or services. Also since an increasing number of hiring managers are turning to social media to search for employees, it makes sense to include a hyperlink to your LinkedIn profile in the Contact information section of the resume
Nancy Range Anderson, Author of Job Search for Moms and President of Blackbird Learning Associates
Before you write your resume:
To out distance your job-seeking competitors, follow this best practice... before writing your resume.
Make a list of 10-15 (or more) mutual good-fit employers to target. Do research on them to determine what makes you uniquely qualified to help them meet their current challenges, for market intelligence, and to uncover relevant keywords and phrases. Use this information to create content for your personal brand messaging and career marketing materials (resume, biography, LinkedIn profile, etc.) that will resonate with those target employer.
Meg Guiseppi, Executive Job Search and Personal Branding Strategist for the C-suite, and CEO of Executive Career Brand
Be specific about your qualifications:
When applying for a position, prepare a cover letter that picks up 3 – 4 key qualifications listed in the job description and be very specific with regards to what you can offer pertaining directly to those qualifications.
Lori Dermer, Dermer Consulting
Career Summaries or Objectives:
A career summary is recommended for most candidates, however there are exceptions. For instance, if you have less than five years of work experience or if you’re changing careers, you’ll want to have a one to two sentence objective statement. Your objective statement should describe the industry you are targeting.
If you’re one of the many candidates that should include a career summary be sure that it is a snapshot of your work experience and offer insight into the skills and attributes you offer. A career summary will typically be in a block paragraph format and run about 3 to 5 sentences long.
John Scott, Career Advocate, Beyond.com – The Career Network
Customize Your Resume:
Each time, before you send your resume for a specific position, research the position and company (including speaking with current or former employees, if you can) so you have a better understanding of the goals and culture of the company, how the position fits within the organization, and the skills and qualities that are an ideal match for the position. Then, customize your resume to reflect the priorities emphasized by the company for this position, using language similar to theirs. This also means resisting the urge to tell them everything you’ve done and can do. Rather, look at your resume from the employer’s perspective. What do they need to know to be moved to contact you for an interview? Select the skills, qualities, accomplishments, and experiences that speak directly to their stated and implied needs.
Shahrzad Arasteh, Author of Nourish Your Career, Holistic Career Counselor, and Speaker
Demonstrate Your Achievements:
Ensure your resume is a forward looking document that demonstrates how your achievements are in alignment with results desired by the hiring organization. Do not write a historically-focused document that simply shows where you have been – show where you are going and how you will add value.
Lisa Rangel, Chameleon Resumes
Focus on Your Accomplishments:
The most important resume tip I offer is that you need to make the focus of the job descriptions listed on the resume a summary of what you accomplished and contributed in each of your positions. Employers are more interested in these than in what you actually did on the jobs. My second most important tip is to tell the truth. Yes, obviously you don’t want to lie about where you worked or what you did, but it’s the little lies that will trip up your application. Things like disguising gaps in employment by only using years or implying that you earned a degree – when you didn’t, give a potential employer a red flag about your integrity.
Susan Heathfield, Human Resources Expert, About.com
Incorporate Keywords:
Print job postings you’re interested in and highlight keywords. Are these words used on your resume? Transform your resume from a job description to a series of accomplishment statements that are of interest to the company by incorporating those keywords.
Distribute your resume to close friends, family, and references and ask them, “Does this resume communicate my strengths and experiences in a way that will be interesting to the person interviewing me?” Friends and family can be excellent resources for pointing out strengths you have not recognized about yourself.
Robin Richards, Chairman and CEO of CareerArc Group
Keywords as Headlines:
Resumes used to feature a list of keywords to entice the computerized Applicant Tracking System (ATS).
Unfortunately, a list of terms isn’t very enticing to human eyes and doesn’t differentiate a candidate from others with the same list of skills. Instead, use these same keywords as “headlines” for bullet items and give an example from your experience. Like this: Project Management: Initiated and implemented national merchandising program for big box retailer.
Jeri Hird Dutcher, National Award-winning Certified Resume Writer, WorkwriteResumes.com
Match Your Resume to Your LinkedIn Profile:
Make sure your resume is online! Once you have your perfect document in place, update your LinkedIn profile so it matches, include your job information on Facebook and Twitter, start an About.me page, or create a professional blog for yourself where your resume information can be posted. When employers search for you online (and they will!), it will be a tremendous help to make it easy for them to find the same information confirming what they’re reading on your resume.
Sara Sutton Fell, Founder & CEO of FlexJobs.com
Not a Laundry List:
A resume should not be a laundry list of “stuff” you’ve done. It is a marketing document, and should directly address the target employer’s needs by including your specific skills and accomplishments. Before writing a resume, be sure to study job descriptions and collect as much information about organizations that interest you as possible. Then, you can make a clear case for why you are the perfect person to address and solve that company’s challenges.
Miriam Salpeter, Author of Social Networking for Career Success, New Economy Job Search Coach & Social Media Consultant, Keppie Careers
Resume Length:
A simple rule with flexibility is that if you have more than seven years of experience, your resume should be two pages. With less experience, write a one page resume. Your resume should never be more than two pages. For people who are older or in areas such as Management Consulting, like myself, create a biography to retain everything you have done.
Jay Martin, Chairman, JobSerf, Inc.
Resumes for Career Changers:
Career changers ask career coaches how to format their resume for a new position or industry but first it would be helpful to do something to signify to hiring managers that you are serious about the new career. Join the professional association, do relevant volunteer work, take a skills-building class. Any accomplishments in your desired career field are better than a beautifully formatted resume that lacks proof that you really know anything about the new career path.
Janet Scarborough Civitelli, Ph.D., Career Coach, VocationVillage.com
Throw Your Resume Out:
The best thing you can do with your resume is throw it out. That’s right: Don’t use a resume to impress an employer, because it won’t. Write a mini business plan for the job instead – and submit it to the hiring manager, not to HR, and not to some “applicant tracking system.” You don’t know the manager? Then you have no business applying for the job. The information you submit should be about the manager and your plan for fixing her problems – not about you. This approach is actually fun, because you must focus on one job at a time, which in turn means you must choose wisely, and meet the manager first. After all, isn’t that how you behave when you’re on the job?
Nick Corcodilos, host of asktheheadhunter.com and author of Fearless Job Hunting
About a year ago, I co-authored with Bruce Yang a whitepaper entitled “Agile in the Federal Government – Moving Beyond Scrum.” In that whitepaper, we predicted that the government would follow the lead of the private sector to adopt Agile solutions beyond Scrum to gain broader benefits. Specifically, the private sector had learned that Scrum by itself would not effectively support scalability to replicate the success of one project across the entire organizational structure and adopted scaling frameworks such SAFe. Similarly, it realized that the Scrum methodology was not necessarily appropriate for all types of work and looked for alternatives, most notably Kanban.
I am happy to report that the federal sector has in fact followed this anticipated pattern. Some examples:
We’re trying to compile a more comprehensive list of agencies that have adopted Agile techniques beyond Scrum and how well they have been working. Would you mind sharing any non-confidential examples that you might be aware of?
As discussed in the first post in this series Agile in the Federal Government – Going, Going, Gone Beyond Scrum, the history of Agile adoption in industry took the path of usage of Extreme Programming (XP) followed by the combination of Scrum and XP. In the government, the adoption of Scrum alone has become the de facto method of Agile adoption with the use of the term Agile and Scrum even becoming synonymous in some agencies. In our latest white paper we discuss why we believe the use of Agile Engineering Practices such as XP is crucial to the success of Scrum projects for the Federal government and that the government can again benefit by combining Scrum with XP as is already in use by industry. We believe this is because Agile Engineering Practices enhance the empirical process control (Inspection, Adaptation, and Transparency) of Scrum.
According to the latest State of Agile Survey by VersionOne, the top three XP techniques in practice are Continuous Integration, Test-First Programming, and Shared Code. What XP practices are you using at your agency? Is the use of them improving quality?
In 1970, Father Horace McKenna, S.J. and an interfaith group of priests, ministers, and lay persons founded So Others Might Eat (SOME) to offer food, clothing and health care to the poor and homeless. CC Pace has long been a supporter of this exceptional organization; and, CC Pace President, Mike Gordon has been a member of the SOME Corporate Advisory Board for fifteen years.
Each year SOME holds their Annual Dinner Gala and Silent Auction to raise funds for a specific need of the organization. This year’s funds will benefit SOME’s Capital Campaign to develop a site on Benning Road in DC that will include housing, job training, offices, retail space and a medical clinic. This year’s event was held November 22nd at the National Building Museum with 850 attendees. The evening was full of a very giving spirit with gracious donors and praise for all the important work being done by SOME. The entire event and silent auction resulted in approximately $1,000,000 of donations.
Highlights of the evening included a touching film featuring Dr. Maya Angelou; and, a tribute to her generous support and contributions to SOME over the years. Each year SOME recognizes members of the community for their outstanding contributions and support with the SOME McKenna Humanitarians of the Year award, this year’s recipients were Ed and Kathleen Quinn. Ed Quinn is the CEO of TW Perry.
Pictured here are CC Pace President, Mike Gordon, his wife Tracy and SOME President, Father John Adams who has directed SOME for more than 35 years.
Keeping with the giving spirit of the holidays, CC Pace has decided to partner with our neighboring tenant AAA and participate in Toys for Tots. CC Pace tries to give back to the community whenever possible and participates in several charitable events throughout the year. This time of year in particular is a great time to remember those that are less fortunate. Toys for Tots is a well-known charity that provides gifts to less fortunate children in the community. The goal of the U.S. Marine Corps Reserves is to ensure no child goes without experiencing the joy of Christmas while also bringing a community together to send a message of hope to these children that will help groom them to become caring and productive members of society. Together, with AAA, we were able to collect over 5 large boxes of toys for some much deserving children. To find out more about Toys for Tots, visit their website here.
Ron Jeffries recently posted an article on writing code for “The Diamond Problem” using TDD in response to an article by Alistair Cockburn on Thinking before programming. Cockburn starts out:
“A long time ago, in a university far away, a few professors had the idea that they might teach programmers to think a bit before hitting the keycaps. Nearly a lost cause, of course, even though Edsger Dijkstra and David Gries championed the movement, but the progress they made was astonishing. They showed how to create programs (of a certain category) without error, by thinking about the properties of the problem and deriving the program as a small exercise in simple logic. The code produced by the Dijkstra-Gries approach is tight, fast and clear, about as good as you can get, for those types of problems.”
To which Ron responds:
“I looked at Alistair’s article and got two things out of it. First, I understood the problem immediately. It seemed interesting. Second, I got that Alistair was suggesting doing rather a lot of analysis before beginning to write tests. He seems to have done that because Seb reported that some of his Kata players went down a rat hole by choosing the wrong thing to test.
“Alistair calls upon the gods, Dijkstra and Gries, who both championed doing a lot of thinking before coding. Recall that these gentlemen were writing in an era where the biggest computer that had ever been built was less powerful than my telephone. And Dijkstra, in particular, often seemed to insist on knowing exactly what you were going to do before doing it.
“I read both these men’s books back in the day and they were truly great thinkers and developers. I learned a lot from them and followed their thoughts as best I could.”
Ron’s article goes on to solve the same programming problem with TDD and no particular up-front thinking that Cockburn solved in what he calls a combination of “the Dijkstra-Gries approach” and TDD. On the whole, I would tend more towards the pure TDD approach that Ron takes because it got him feedback earlier and more frequently, while Cockburn’s approach, with more upfront thinking, didn’t provide him any feedback until he really did start writing his tests. If Cockburn had gone down a blind alley with his thinking, he wouldn’t have gotten any concrete feedback on it until much later in the game.
But that’s not what I actually want to think about. I did read both Dijkstra’s A Discipline of Programming and Gries’ The Science of Programming “back in the day” as well (last read in 1991 and 2001, respectively, although it was a second reading of Gries; I remember finding Dijkstra almost impossible to understand, but I did keep it, so it may be time to try it again), but I didn’t remember the emphasis on up front thinking that both Ron & Cockburn seemed to claim for them. I dug out my copies of both books and did a quick flip through both of them, and I still feel that the emphasis is much more on proving the correctness of one’s code rather than doing a lot of up-front thinking. I’d previously had the feeling that there was a similarity between Gries’ proofs and doing TDD. As I poke around in chapter 13 of Gries’ book, where he introduces his methodology, I find myself believing it even more strongly.
Gries starts out asking “What is a proof?” His answer?
“A proof, according to Webster’s Third New International Dictionary, is ‘the cogency of evidence that compels belief by the mind of a truth or fact,’ It is an argument that convinces the reader of the truth of something.
“The definition of proof does not imply the need for formalism or mathematics. Indeed, programmers try to prove their programs correct in this sense of proof, for they certainly try to present evidence that compels their own belief. Unfortunately, most programmers are not adept at this, as can be seen by looking at how much time is spent debugging. The programmer must indeed feel frustrated at the lack of mastery of the subject!”
Doesn’t TDD provide that for us, at least when practiced correctly? Oh, and the first principle that Gries gives in this chapter is: “A program and its proof should be developed hand-in-hand, with the proof usually leading the way.” Hmm, sounds familiar, no?
Admittedly, Gries does speak out against what he calls “test-case analysis:”
“‘Development by test case’ works as follows. Based on a few examples of what the program is to do, a program is developed. More test cases are then exhibited – and perhaps run – and the program is modified to take the results into account. This process continues, with program modification at each step, until it is believed that enough test cases have been checked.”
On the face of it, this does sound like a condemnation of TDD, but does it really represent what we do when we really practice TDD? Sort of, but it overlooks the critical questions of how we choose the test cases and the speed at which we can get feedback from them. If we’re talking randomly picking a bunch of test cases and getting feedback from them in a matter of days or hours, then I’d agree that it would be a poor way to develop software. When we’re practicing TDD, though, we should be looking for that next simplest test case that helps us think about what we’re doing. Let’s turn to Gries’ “Coffee Can Problem” as an example.
“A coffee can contains some black beans and some white beans. The following process is to be repeated as long as possible.
“Randomly select two beans from the can. If they have the same color, throw them out, but put another black bean in. (Enough extra black beans are available to do this.) If they are different colors, place the white one back into the can and throw the black one away.”
“Execution of this process reduces the number of beans in the can by one. Repetition of the process must terminate with exactly one bean in the can, for then two beans cannot be selected. The question is: what, if anything, can be said about the color of the final bean based on the number of white beans and the number of black beans initially in the can?”
Gries suggests we take ten minutes on the problem and then goes on to claim that “[i]t doesn’t help much to try test cases!” But the test cases he enumerates are not the ones we’d likely try were we trying to solve this with TDD. He suggests test cases for a black bean and a white bean to start with and then two black beans. Doing TDD, we’d probably start with a single bean in the can. That’s really the simplest case. What’s the color of the final bean in the can if I start with only a single black bean? Well, it’s black. And it’s going to be white if the only bean in the can is white. Okay, what happens if I start with two black beans? I should end up with a black bean. Two white beans wouldn’t make me change my code, so let’s try starting with a black and a white bean. Ah, I would end up with a white bean in that case. Can I draw any conclusions from this?
I did actually think about those test cases before I read Gries’ description of his process:
“Perhaps there is a simple property of the beans in the can that remains true as the beans are removed and that, together with the fact that only one bean remains, can give the answer. Since the property will always be true, we will call it an invariant. Well, suppose upon termination there is one black bean and no white beans. What property is true upon termination, which could generalize, perhaps, to be our invariant? One is an odd number, so perhaps the oddness of the number of black beans remains true. No, this is not the case, in fact the number of black beans changes from even to odd or odd to even with each move.”
There’s more to it, but this is enough to make me wonder if this is really different from writing a test case. Actually it is: he’s reasoning about the problem, and by extension the code he’d write. But he is still testing his hypotheses, it’s just in his head rather than in code. And there I would suggest that TDD, as opposed to using randomly selected test cases, allows us to do that same kind of reasoning with working code and extremely rapid feedback. (To be fair, I believe this is what Ron was saying, too. I just want to highlight the similarity to what Gries was saying, while Ron seems to be suggesting more of a difference.)
What might get lost in TDD, at least when it’s not practiced well, is that idea of reasoning about the code. There’s an art to picking that next simplest test to write, and I suspect that that’s where much of the reasoning really happens. If we write too much code in response to a single test, we’re losing some of the reasoning. If we write our tests after the code, we’ve probably lost it entirely. And that’s something I do believe is lacking in many programmers today, evidenced, as Gries suggests, by the amount of time spent fumbling around in debuggers and randomly adding code “to see what will happen.” But that’s for another time.