Trust is an exceptional quality that we humans can develop with each other. It goes a long way to building positive relationships. We hope and strive for trust in our families, and with our most intimate connections. Yet do we expect trust in our work lives?
Can you imagine the relief you might feel entering your work space, knowing that you can do your work with confidence and focus? That encouragement rather than criticism underlies the culture of your workplace? That a manager or co-worker is not scheming behind your back to knock you or your efforts down in any way? That you’re not being gossiped about?
Trust is especially key in today’s work spaces. Teamwork is becoming an essential aspect of work across every kind of business and organization.
Here’s what one team development company writes about this subject:
The people in your organization need to work as a team to respond to internal and external challenges, achieve common objectives, solve problems collaboratively, and communicate openly and effectively. In successful teams, people work better together because they trust each other. Productivity improves and business prospers. http://beyondthebox.ca/workshops/team-trust-building/
It Starts With Me and You
As with so many qualities in life, the idea of trust, or being trustworthy, starts with me and you.
It is essential that we take a hard look at ourselves, and determine whether or not we display the attributes of trustworthiness.
To do this, I might ask myself some of these questions:
Do I tell the truth?
Do I avoid backbiting (talking about others behind their back)?
Do I do what I say I’m going to do?
Do I apply myself to my work and do my best?
Do I consciously build positive relationships with all levels of people in my workplace?
Do I encourage or help others when I can?
There are many more questions to ask oneself, but these offer a place to start.
One website proposesa template to assess employees in terms of their trustworthiness:
Trust develops from consistent actions that show colleagues you are reliable, cooperative and committed to team success. A sense of confidence in the workplace better allows employees to work together for a common goal. Trust does not always happen naturally, especially if previous actions make the employees question if you are reliable. Take stock of the current level of trust in the workplace, identifying potential roadblocks. An action plan to build positive relationships helps improve the overall work environment for all employees.
This snippet comes from “Lou Holtz’s Three Rules of Life,” by Harvey MacKay:
“The first question: Can I trust you?”
“Without trust, there is no relationship,” Lou said. “Without trust, you don’t have a chance. People have to trust you. They have to trust your product. The only way you can ever get trust is if both sides do the right thing.”
Six Sigma is a methodology which has been used for more than 30 years to deliver great strategic and financial results. It has brought significant results for industries and companies from different industries.
I am a Master Black Belt in Six Sigma, and for the past 15 years I have trained over 5,000 people and conducted projects for many companies in South America, North America, and Europe.
Globalization has shortened the distance between customers and business, requiring more speed and adaptability from companies to sell their products and services.
Through a combination of training and consulting in Six Sigma, my team has been supporting organizations to embrace projects towards variability reduction as well as waste elimination to increase customer satisfaction. Millions of dollars have been saved, and we have satisfied our stakeholders.
The reward for our success was that project opportunities came flowing in, yet we were challenged to complete projects even faster and better than before. How could my team do that? We needed to figure out a way together. More and more frequently we were collaborating with our customers and stakeholders to understand exactly what was important. We were inviting the team, analyzing many possibilities, rethinking our approach and then implementing the new framework.
The business environment forced new techniques to achieve different results. I realized that if I challenged our team at the planning meeting stage, we would find new ways to reach the goal (most of the time utilizing a better approach than before). Even if, during the process, we encountered a roadblock, we were able to involve the team to find a creative solution. We found we could do almost anything because we had created an environment of trust.
All along, our stakeholders were aware of what was happening, and they were encouraging the team to keep using the ‘new strategy.’ We stopped wasting our time with delays, dropped the useless documentation, while always ensuring that people were seen as more important than the process. Because of this, we were already delivering results faster than expected and had started the process of becoming Agile.
David Vicentin, Director of Business Development, BERTEIG
Lean Six Sigma Master Black Belt, Coach, Trainer and Agile practitioner, has more than 15 years in management consultancy experience delivering operational excellence and Agile implementation across various businesses. His experience and capabilities have taken him to Spain, United States, Mexico, Brazil, UK and Canada. David’s enthusiasm and practical coaching experience have allowed him to mentor senior managers to achieve sustainable results. An Industrial Engineer with a Masters degree in Economics and Finance, David is able to create an environment of learning in various fields of work.
Over the years I have done a number of talks for local chapters of the Project Management Institute. They have covered a range of topics, but one common theme that comes up over and over is that Scrum is not the best Agile method for delivering an IT Project. I even published a short video on the topic:
Several years ago, I also published a short article describing what Scrum is good for:
So… if Scrum isn’t so good for IT project work, then what can bring real agility to IT projects?
IT Project Attributes
Most of my work experience prior to running my business was in IT projects in banking, capital markets, insurance and a bit in government and healthcare. I mention that merely to indicate that my discussion of this isn’t just theoretical: I’ve seen good projects and bad projects. I’ve been on death-march projects, small projects and massive projects ($1b+). I’ve dealt with regulatory issues, vendor issues, offshoring issues, telecommuting issues, architectural issues, political issues, and seen enough problems to understand the complexity of reality.
IT projects have some common characteristics:
Like any project, there’s a deadline and a scope of work and a budget. These things don’t work well with Scrum. It’s possible to force them to fit together, but you lose a lot of what makes Scrum effective.
IT (as opposed to, say, tech startups) tends to use more mature technology platforms. Scrum is neutral about technology, but there are other Agile methods that address this type of technology more effectively.
IT Projects are often not the only thing going on in the technology organization. In particular, operations and user support add to IT project complexity, and require different “classes of service” than Scrum provides.
The issues that I mentioned above such as regulation, vendors, offshoring etc. are also common attributes of IT projects. Scrum makes harsh demands on an organization that challenge the approach to dealing with these issues. The change required to accommodate Scrum may not be worth it.
The Bad News about IT Project Agility
The whole project orientation to IT work is questionable. It’s just not a good fit. In most mid- to large-size organizations, IT does two things: it provides technology services to the rest of the organization, and it provides technical product development capacity to lines of business. For example, upgrading the office wi-fi routers and adding a new payment type to the online customer portal, respectively. The work of the IT department, therefore, falls into several different categories:
New artifacts that need to be created. Usually this is the stuff like coding algorithms and other business logic, creating new databases, configuring purchased systems, etc.
Repetitive activities that need to be sustained for a period or indefinitely, or which occur on-demand but at irregular times. For example, running a nightly batch process or deploying an update to a production environment.
Quality problems that need to be fixed. Defects and production problems are the obvious categories here, but also quality problems that are causing user confusion or time wastage.
Obstacles to work that need to be overcome. Often obstacles come from outside the project team in the form of interruptions. Other forms of obstacles can be unexpected bureaucracy, shifting funding, problems with a vendor, etc.
Calendar events that need to be accommodated. Milestones in the project, particularly regulatory milestones are crucial in IT project work, there are many other types such as all-hands meetings, statutory holidays, hiring or contract end dates, etc.
Of these, only repetitive activities and calendar events fit well into a project perspective. The others typically have a level of uncertainty… complexity… that makes it very difficult to approach with the project perspective of fixed deadlines and scope.
On the other hand, Scrum only really handles new artifacts and obstacles directly, and quality problems indirectly. These are the kinds of activities that are the focus of product development. Repetitive activities and calendar events are anathema to the core Scrum framework. If I think about this from a scoring perspective, Scrum supports these kinds of work as follows (-5 means totally counter, 0 means no impact, +5 means total support):
Scrum Support for IT Project Work Types:
New artifacts: +5
Repetitive activities: -2
Quality problems: 0
Obstacles: +4
Calendar events: -5
SCORE: +2 – barely positive impact on IT project work!!!
The bad news, therefore: neither a project orientation nor Scrum really cover all the needs of an IT project environment.
There are many, but these are my three favourite alternatives: Extreme Programming, Kanban and OpenAgile. All three of them cover the five types of work more effectively than Scrum. All three of them are oriented to more generic types of work. After describing each briefly, I’ll also mention which one is my top choice for IT project work.
Extreme Programming for IT Project Work
Historically, Extreme Programming (XP) emerged in an IT Project context: the famous C3 project at Chrysler. This approach to IT project work has many things in common with other approaches to agility (which are described in the Agile Manifesto). XP allows the five types of work as follows:
New artifacts are the core of XP and are usually expressed as User Stories. This is common to Scrum and many other Agile methods. These are typically the features and functionality of a system… the scope of the project work. XP does not make any strong assertions about the size or stability of the backlog of new artifacts and as such can accommodate the project orientation in IT with relatively fixed scope.
Repetitive activities are not explicitly addressed in XP, but nor is there anything in XP which would cause problems if an XP team is required to do operational or support work which is the source of most repetitive activities in an IT environment.
Quality problems are addressed directly with both preventative and reactive measures. Specifically, Test-Driven Development, Acceptance Test-Driven Development are preventative, and Refactoring and Continuous Integration are reactive. XP has a deep focus on quality.
Obstacles are not directly addressed in XP, but indirectly through the XP value of courage. Implicitly, then, obstacles would be overcome (or attempted) with courage.
Calendar events are not addressed directly for the most part with the exception of release planning for a release date. However, the stuff related to other calendar activities is not directly handled. XP is less antagonistic to such things than Scrum, but only by implication: Scrum would often put calendar events in the category of obstacles to be removed to help a team focus.
XP Support for IT Project Work Types:
New artifacts: +5
Repetitive activities: 0
Quality problems: +5
Obstacles: +2
Calendar events: +1
SCORE: +13 – moderate to strong positive impact on IT project work!
Summary: much better than Scrum, but still with some weaknesses.
Kanban for IT Project Work
Kanban is different from most other approaches to agility in that it is a “continuous flow” method, rather than an iterative/incremental method. This distinction basically means that we move packages of work through a process based on capacity instead of based on a fixed cadence. Kanban asks that we visualize the current state of all work packages, limit the amount of work in progress at any stage in our delivery process, and use cadences only for iterative and incremental improvement of our process (not our work products).
Kanban is much gentler than Scrum or Extreme Programming in that it does not require leader-led reorganization of staff into cross-functional team units. Instead, we identify a service delivery value stream and leaders manage that stream as it currently operates.
New artifacts in Kanban are supported, and certainly welcome, but Kanban does not seem to acknowledge the problem of formal complexity (creativity, problem-solving, human dynamics) in the creation of new artifacts. There are good attempts to apply statistical methods to the management of new artifacts, but their fundamentally unknowable cost/end (undecidable problem) is not really effectively addressed.
Repetitive activities are handled extremely well in Kanban including different classes of service. Repetitive activities are handled well partly as a result of the history of Kanban as a signalling system in manufacturing environments.
Quality problems are handled similarly to new artifacts: supported, welcome, and even possibly addressed in the cadences of continuous improvement that Kanban supports. However, quality problems are another area where technical complexity makes proper analysis of these activities difficult.
Kanban relegates the handling of obstacles to the manager of service delivery. There is no explicit support for strong organizational change efforts. In fact, Kanban discourages “transformative” change which is sometimes required given the problem of Nash equilibriums.
Kanban works well with Calendar events by treating them as activities with a particular class of service required.
Kanban Support for IT Project Work Types:
New artifacts: +3
Repetitive activities: +5
Quality problems: +3
Obstacles: 0
Calendar events: +5
SCORE: +16 – strong positive impact on IT project work!!
Summary: even better than XP, easier to adopt. (Actually, almost anything is easier to adopt than XP!!!)
OpenAgile for IT Project Work
OpenAgile is an obscure non-technology-oriented method based on the work I and a few others did about 10 years ago. The OpenAgile Primer is the current reference on the core of the OpenAgile framework. OpenAgile has been applied to general management, small business startups, sales management, mining project management, emergency services IT, and many other areas of work. I’m partial to it because I helped to create it!
OpenAgile emerged from consulting work I did at CapitalOne in 2004 and 2005 and work I did with my own business in 2006 and 2007. A great deal of the older articles on this blog are forerunners of OpenAgile as it was being developed. See, for example, Seven Core Practices of Agile Work.
The types of work listed above, are indeed the core types of work described in OpenAgile. As such, OpenAgile fully supports (nearly) all five types of activities found in IT projects. However, OpenAgile is not just a work delivery method. It is also a continuous improvement system (like Kanban and Scrum) and so it also assumes that a team or organization using OpenAgile must also support learning. This support for learning means that OpenAgile does not over-specify or give precise definitions on how to handle all five types of work. Thus, my scores below are not all +5’s…
OpenAgile Support for IT Project Work Types:
New artifacts: +4
Repetitive activities: +4
Quality problems: +4
Obstacles: +4
Calendar events: +4
SCORE: +20 – very strong positive impact on IT project work!!!
Summary: OpenAgile is the best approach I know of for general IT project environments.
Conclusion
Regrettably, I wouldn’t always recommend OpenAgile – there are just too few people who really understand it or know how to help an organization adopt it effectively. If you are interested, I’d be happy to help, and we can certainly arrange private training and consulting, but mostly I would recommend Kanban to people interested in taking the next step in effectiveness in IT projects. Please check out or Kanban learning events and consider registering for one or asking for us to come to your organization to deliver training, coaching or consulting privately.
So, what “awful circumstances” led to Equifax’s recent breach?
Let’s reflect: News has surfaced (TechCrunch, Reuters) that hackers have scraped untold amounts of sensitive data from Equifax systems. 143+ million people are affected as hackers have amassed a huge database of names, addresses, credit records, license numbers, banking histories. (That probably includes you too!)
I want to be clear though, the news broke yesterday but the problem started long ago. The security vulnerability has existed for (probably) years and I have no doubt some Equifax staff have known about it.
Equifax! We’re not talking about some high-school project with junior coders and tech newbs. We’re talking about one of the world’s most trusted organizations. We’re talking about a company whose very existence (their whole business!) is to protect our collateral. This is supposed to be one of the best-funded, most secure, most technologically-advanced companies on the planet.
But I’m not surprised. Here’s why…
I teach Scrum and my classrooms are filled regularly with people who work in companies exactly like Equifax. I hear their stories every day:
“Our managers don’t provide the tools we need to do the job.”
“Our managers don’t understand the time required to deliver high-quality software. We’re always pressured to cut corners to meet arbitrary and impossible deadlines.”
“Our systems are broken, everyone knows it, but managers continue to outsource and off-shore our QA.”
“We don’t have authority to decide the implementation, we’re often told what to implement by architects and supervisors, even if we know it to be rotten.”
“Our managers never ask us about quality…they ask us only ‘when will this be done’?”
And that’s the crux of the problem: people are hired by companies like Equifax to provide technical expertise, then their advice is ignored and their implementation decisions aren’t trusted.
Some important questions to consider…
1. Does Equifax lack the money to hire excellent technical staff?
No, their offices are filled with some of the best programmers in the world. I meet them (or people like them) regularly in my classes and I have no doubt that the technical staff at Equifax have warned the managers for years of security holes and technical defects. I have no doubt those managers have ignored the alarms and have pushed the staff to deliver deficient code.
2. Does Equifax lack the time to build high-quality systems?
No, last I checked they’ve been at it a long time and their existing contracts will carry their operation years into the future. And as mentioned earlier, securing our data is the reason the company exists. It’s the one thing they’re supposed to get right – I’d think their time should be entirely devoted to building high-quality systems.
3. Does Equifax lack the financial resources to invest in proper tools and training for security/quality testing?
No, such techniques and tools are widely available and inexpensive (even hackers can afford them!) Managers at Equifax have denied budgets for training, tools, and upgrades because “it’s too costly” – hmm…I wonder the cost of this data breach?
4. And my favourite question of the day: Are the hackers “smarter”?
Absolutely not. But they’re more dedicated and have equipped themselves with good techniques and tools for penetration testing. In my personal experience as a hacker (er, I use that term loosely) security holes are all around us if we look for them. Equifax simply wasn’t looking!
What to do about it…
First, it’s clear to me the problem isn’t technical or financial. It’s cultural. I see it all the time. Teams of good product developers are surrounded by bureaucracy instead of support. Teams of good coders aren’t trusted to see the source code of the systems used by the company – yes, that’s as crazy as it sounds! Teams of good coders are kept silent about the security vulnerabilities they see. Solutions are ignored by management and the arguments are: “improving the security isn’t a priority right now” or “we know there are some possible security concerns and we are in discussion with vendors or outside agencies to address it” or “we have a budget for security improvements scheduled for next quarter; let’s focus for now on new features instead”. Managers are more concerned with deadlines than with quality. Managers scrutinize the number of hours a developer works on a task, and outsource or off-shore the quality assurance and testing! Managers conduct endless planning activities then compress the implementation into tight budgets and timelines – evidently, a lot of energy is spent getting the plan “right” but getting the software right is not a priority. I could go on.
If you’re interested to know how things work at Equifax, just think of the Dilbert cartoons. I mean it. I am very serious. Dilbert isn’t funny because it’s fiction; it’s funny because it’s NON-fiction. Sadly. Typically, for enterprises like Equifax, their technical staff and customers take a back seat to management “theatre”. This needs to be fixed and it starts by asking the technical staff a single, simple question: “Who among you have raised concerns about technical debt with your managers/supervisors and were ignored?” That question will unearth bugs which have been deprioritized by managers, budgets that have been denied for technical training and automated testing, projects which have been reported as “done” before they were actually ready for deployment – in other words, that question will reveal the many (fixable) ways managers get in the way of quality.
Second, executive staff at Equifax need a crash course in automated testing. Yes, THE EXECUTIVE STAFF! It’s is essential they understand and see with their own eyes that:
Automated testing is cheaper and exponentially more effective than manual testing;
ALL defects are discoverable and fixable before hitting production environments;
Quality is not something one outsources
and the techniques to achieve ZERO DEFECTS are well-known, teachable, repeatable, and proven. I’m of course referring to techniques like Test-Driven Development, Continuous Integration, Refactoring, and Swarming. For example, these technical topics form the bulk of our Certified Scrum Developer classes. (Shameless plug.)
And third, technical staff need to stop behaving like sheep. So far in this article, I’ve been very critical of managers, sure, and anyone who knows me personally knows I have no time for inept management. But too often I meet smart, well-meaning developers who deliver shoddy code – perhaps at under pressure and against their better judgement, but in the end whose code is it? Developers! I understand you might feel trapped in a pattern of quantity-over-quality and you are frequently coerced by your management to cut corners. I get it… I understand it… it’s easy to feel that deadlines are some sort of immutable truth and that managers wield all the power. But the fact is, developers, YOU hold all the responsibility and therefore you need to be the professional. You need to say “no” and demand the latitude you require to deliver high quality. You’re the one closest to the code and therefore directly responsible for the safety and well-being of your users.
So, Equifax and enterprises everywhere, I’m speaking now as your user or stakeholder or customer…
Equifax has failed. Miserably. The company deserves all the class-action suits coming there way. From leaders to developers. Everyone.
Most members of society are unwilling participants in all this. Most of us aren’t your direct customers. Example: I’m not a direct customer of Equifax – nobody has chosen Equifax as their personal agent. Instead, our banks and our governments have selected Equifax on our behalf. This presents a problem: if I were a direct customer of Equifax I’d call them today and close my accounts; but I can’t do that. Instead, the best I can do as an individual is contact my banks, lenders, and insurance agents to demand change. (Yes, I likely will do that. I’m that sort.)
However, the larger issue is that we are at the mercy of YOU who produce software. I’m talking about the software in our vehicles, in our heart-monitors, in our subway systems, in our air-traffic-control centres, in our banks – this is serious stuff! We must be able to trust those systems…with our lives, with our security. We must be able to trust you even though we don’t and won’t ever know you.
A hacker friend of mine once said, “if self-driving cars are being produced without complete automated test coverage, then that’s a future I don’t want.”
Do you want love in your work life? Is it a possibility? Would love in your work life put a spring in your step as you leave home each morning?
To be clear, this topic not about romantic relationships with colleagues at your work place. The love I’m proposing is wedding love for your work with loving affection for and from everyone you deal with in your workplace. If your answer to the initial question is “yes,” then read on.
Personal History
I previously taught theatre courses at universities for over 20 years. I loved my subject. I loved watching students transform, sometimes from insecure, self-conscious, wary creatures, to confident, trusting and expressive performers. How did this happen?
In my approach to teaching, I made every effort to nurture students with care and affection, to create a safe and trusting space for them, to provide them with the best learning tools I could find to strengthen their capacities. I tried to understand each individual’s particular needs. I cared that every student would advance.
My door was always open to them outside of class. Sometimes a student would come to me with personal problems that ostensibly had nothing to do with their course work. I listened with empathy. I made sure that I was trustworthy in my responses and actions.
For example, I never asked anything of my students that I myself wasn’t willing to perform. I nudged them, sometimes gently, sometimes more strongly (depending on their nature), to move outside their comfort zone. This often resulted in break-through and exhilarating experiences for the student.
In other words, I loved my work and my students!
What Creates Safety?
The highest percentage of people who have been polled about which cultural attribute is most important to them in their workplaces list “safety.” By safety, they usually mean things like “feeling safe to express my self;” “safe to have a difference of opinion;” “safe to sometimes fail without negative repercussions.”
If we look for the root of what helps us feel safe, I think we can trace it back to receiving human affection and loving care. This is what causes us to stay with a marriage partner over time. It creates lasting bonds with our children, family members, and long-time friends. Why should this attribute be absent from our workplaces?
Have you ever asked yourself: “Do I stay in this job because I intrinsically like it, but have the urge to flee because its culture is unsafe and unloving?”
Think about yourself as a kid in school when you had a favourite teacher. Who was s/he? Why was s/he your favourite? Was s/he especially kind or affectionate? Encouraging? Generous with her time? Think of the way s/he managed her class of several children.
Now think about a person in your workplace with whom you do not feel safe, and imagine that this person is actually like the teacher who was your favourite. How does that change how you feel about that colleague? How differently might you react to him/her?
Giving Love
It may sound trite, but it’s been proven that one of the ways to receive love is to give it. It can start with your thoughts toward a difficult manager or colleague. Reflect on this statement:
When a thought of war comes, oppose it by a stronger thought of peace. A thought of hatred must be destroyed by a more powerful thought of love. Thoughts of war bring destruction to all harmony, well-being, restfulness and content. Thoughts of love are constructive of brotherhood, peace, friendship and happiness.
A wonderful article by Sigal Barsade and Olivia A.O’Neill in the Harvard Business Review discusses a culture of love in the workplace. Here’s a snippet from their article (which is worth reading in its entirety):
We conducted a follow-up study, surveying 3,201 employees in seven different industries from financial services to real estate and the results were the same. People who worked in a culture where they felt free to express affection, tenderness, caring, and compassion for one another were more satisfied with their jobs, committed to the organization, and accountable for their performance.
I first encountered love as a conscious factor in the business world when I joined BERTEIG. Its founder, Mishkin, spoke often about the importance of expressing love in his training, consulting and coaching events. I found this fascinating, because my impression of big business was that of cool efficiency.
On the BERTEIG website, you can find this Vision Statement:
We co-create sustainable, high-performance organizations where continuous improvement is deeply embedded in the culture. We believe truthfulness is the foundation of improvement, and love is the strongest driver of change.
For the past five years, I have seen the benefits of that vision of love being a strong driver of change in the BERTEIG team. Despite being a very diverse group of people, we have a great deal of affection for each other. This affection enables us to grow, to continuously develop our capacities, to openly disagree with each other, and to offer our best. Clients who attend our training courses sometimes gush (yes, gush) about their trainer. Affection not only helps our own internal collaboration but our external as well. When we commit to a project/ job/ event, we follow through because we care.
One of the beautiful things about love is that it will radiate out to whomever we work with, andto whatever social spaces we participate in.
Now – You!
Do you want love in your work life? Do you believe love can be the strongest driver of change? If so, how can you action this in your own workplace?
