The Future is Flexible
When it comes to work trends, one thing is clear: the future is all about flexibility – but what does that really mean? Like many things, it tends to mean something different to just about everyone, as there is no ‘one-size-fits-all approach’ when it comes to applying it to the workplace. As many companies seek to craft their definition of adaptable work policies, CC Pace is in the middle of the crosscurrents in deciphering the right balance of flexibility, both for our staff and our team of consultants who are navigating various clients’ policies and expectations.
While we can’t tell you what policies are right for your organization, we can share some of the impacts we’ve seen these decisions have when it comes to recruiting. It should come as no surprise that companies with the strictest remote work policies are having the hardest time finding, and retaining, top talent. They’re having to dig deeper into their pockets to make a hire and are losing good employees to their competition at unprecedented rates. In fact, according to a recent poll, 54% of workers said they’d leave their current job for one that provided more flexibility.
Employers with varying ranges of flexibility (hybrid to fully remote options) attract up to an average of seven times more applicants than fully onsite positions (CareerBuilder). Job seekers have spoken, and they want flexible work options. So much so that, on average, they are willing to take a 14% salary decrease to work remotely, according to a recent survey by ZipRecruiter. Companies with flexible options are less likely to roll out the red carpet to get top talent and go into high-stakes salary negotiations compared to their inflexible competitors.
While employees mostly adjusted well to the changing landscape of this new work environment, companies (read: management), have had mixed results. We see continued refinements as hiring managers try to balance where the future is headed with how their positions stack up relative to the competitive alternatives that job seekers have. This often leads to misaligned expectations – job requirements that say, “completely remote,” to maintain a competitive edge, while managers casually mention to the recruiters that they’d ‘really like it if the candidate was within driving distance to the office’ so that they could ‘occasionally meet up.’ In other cases, all positions are hybrid roles, with no exceptions (although exceptions are made for the ideal candidate). This behavior is confusing and can contribute to a costly increase in turnover as current staff asks, “but what about me?”.
In our experience as a consulting firm, this newfound ability of clients to work with a hybrid/distributed workforce has allowed us to expand with clients that we would not have previously been able to support. Take a manufacturer who is located far from a major city; working with them to transform their IT department would have been cost-prohibitive in terms of sustained travel expenses. The happy middle ground here is spending some time face-to-face up front to establish the basic bonds necessary to be successful throughout the engagement. In this case, we need an employee who can ‘travel a little’ and would rule out anyone who cannot. Surprisingly, there are plenty of job seekers that remain adamant on being ‘fully remote’.
These observations don’t appear to be post-pandemic trends that will die out when the market shifts. In the world of technology services, we have seen that when the C-suite mandates ‘no remote work,’ it pushes away the top talent. After all, these are the same people logging in from home on the weekend when the system goes down, aren’t they? Beyond location, Europe’s 4-day workweek trial run in 2022 caught the attention of both employees and employers alike (albeit maybe for different reasons) and has inspired a lot of chatter stateside. Currently, Maryland has a bill on the table that, if passed, would offer major tax incentives to any businesses that scale back to a 4-day (32-hour) work week without employees losing any pay or benefits. It would be a major shakeup to the US workforce. But that’s for another post…
The bottom line is flexibility isn’t just good for your employee morale. It’s good for your bottom line. Companies with the right balance of flexibility save on upfront recruiting costs, employee turnover and can find higher-quality resources than their less-flexible counterparts. The haves and the have-nots have turned into the flexible and the inflexible.
All sides point to flexibility as a work trend that’s here to stay. In response to this trend, we’re creating an ease of coworking index offering to help organizations measure how easy it is for employees and teams to work together – particularly in remote and hybrid environments. Keep an eye out for this service to be released later in the year!
“Our people are our most important asset” is one of the phrases you will not only hear CC Pace CEO Mike Gordon emphasize frequently but is a belief that he has cultivated a corporate culture around. With that philosophy in mind, the Superior Performance Award (SPA) was created. This special award is a way for employees to recognize fellow employees, by nominating a team member who they feel has had a pivotal positive impact towards the success of CC Pace. For the recent performance period, the peer-to-peer SPA honorees are Laura Campbell and Jon Buckhout for their outstanding contributions.
LAURA CAMPBELL has had the lead role in developing our Client Success Program. The program is designed to increase engagement with our consultants and clients and has proven to be highly effective in producing additional value for both the client and CC Pace. Laura was praised by her peers for being a team player extraordinaire, who has made CC Pace better as result of her efforts contributions, and the immense value she brings to so many areas of the company.
JON BUCKHOUT has been a consistent top-performing consultant for CC Pace since joining us in 2008. A key player at a major client, Jon is a sought-after subject matter expert in the mortgage loan arena educating lenders across the country on addressing standards in the mortgage industry. He exemplifies the attributes we look for in consultants with his ability to convey this information in a cohesive manner and form so many lasting connections.
In addition to our SPA recipients, a Service Award was presented to LAUREN IEZZONI for celebrating her 10 Year Anniversary with CC Pace. Lauren is our Graphics Manager with the Midas touch where everything she produces turns to gold when it comes to CC Pace’s branding. Her sense of design and visual elements have taken our corporate branding to a new level. Lauren’s talents, willingness to help at a moment’s notice and constant enthusiasm are extremely appreciated by the entire CC Pace team.
Cheers and a big thank you to our award winners!
Pt 1 of a two-part series
Effective communication remains at the very heart of team efficiency. Entire business models are based on improving team communications, look no further than SalesForce’s acquisition of Slack. Microsoft Teams, BaseCamp, Sharepoint, Zoom, Webex, instant messenger, and text are just a few of the frequently used communication tools in the workplace. Meeting facilitation is now a ‘service offering’ – take a moment and search LinkedIn… perhaps you’ll get more than the 7,700 results that I returned!
Yet here we are in this post-COVID, hybrid/remote work environment, and one of the most effective and proven communication channels has been cast aside. COVID brought most technology work into the home somewhat permanently, and the overscheduling of meetings proliferated, where thanks were provided to higher powers when a meeting was gracefully ended 50 mins after the hour, allowing a few minutes to check on the kids, feed the whining dog, or run to the bathroom—really anything other than staring at an array of faces staring back at their screens. What this also brought was the feeling that since schedules were so solidly stacked, the last thing that made sense was to just call someone. It felt intrusive and presumptuous.
While COVID remains in circulation, the work world is transitioning with some firms fully remote forever, others hybrid with overlap day mandates, and others fully back to pre-pandemic norms. At CC Pace, we remain convinced that flexibility is critical to our employee’s success, but we are also strong believers that face-to-face time is time well spent. I’m reminded of my first job in technology working for one of the Big 4 firms; at my first project, if I hadn’t had the opportunity to strategically place myself at a senior developer’s desk as his day started to ask a few questions and get a few answers, I’d have been sunk. The informal communication channel is critical—and I couldn’t imagine posting my question to him on Teams (even if it had existed back then), nor would he have answered! So how can that experience be replicated within the modern hybrid/remote work environment?
Virtual stand-ups remain useful. Pair programming has its place. Yet we see questions left overnight, where there is a desire not to bother a fellow developer. One of the most basic behaviors that our Agile coaches are pressing on is to push developers to ‘pick up the phone and call’. This deference has a huge cost on team productivity as “stuck developer time” ticks away to no effect.
This is Sachin, picking up with the perspective of a Sr. Scrum Master and Agile coach, I have seen a shift in mindset with team members content with completing their part in a user story. It’s more of a “throw it over the wall” kind of mindset. I usually relate it to a very popular British party game we used to play as kids, i.e., “Pass the parcel.” The parcel, which is the user story, is passed on from one person to another until the music stops, which is when the sprint ends. The result is an incomplete story that just moves on from one sprint to another. The concerning part is team members are not willing to take responsibility for a user story. A simple question, such as “can you finish the user story in a sprint?” goes unanswered. Take, for example, a backlog refinement session: this session is productive when team members communicate and ask questions. But when you consider them as a waste of time and just want to get done with them, assumptions are made without proper analysis, leading to improper sizing and stories remaining “not done”. To some extent, teams and programs have started to blame the very process for missing a deadline.
Effective interactions remain paramount for Agile teams. The efficiency of text, email, and other one-way transmissions is not always effective.
In Part II of this series, Mike Wittrup will talk about a framework that CC Pace uses to assess and improve team communication protocols in the co-working world that we all live in.
In the meantime, we remain at your service in providing tailored approaches to driving business agility. For over 20 years we’ve earned clients’ trust across all stages of the Agile journey. Give us a call!
In early 2022, my wife and I noticed a slight drip in the kitchen sink that progressively worsened. We quickly discovered that if we adjusted the lever just right, the drip would subside for a while. Right before the holidays, we had an issue with our water heater that wasn’t so livable, so we called an expert. After the plumber finished up with our hot water tank, we asked him to check our sink. In 5 minutes, he fixed the problem that had inconvenienced us for months! We had become so used to our workaround that we didn’t even realize how much time we spent in frustration trying to get the faucet handle just right (let alone double checking it all hours of the day and night) when we could have resolved the issue in just a few minutes of effort from an expert!
Sometimes, our workarounds are only efficient in our minds. They may save us time or a few dollars upfront, but do they save us anything in the long run? In my case, the answer was a resounding ‘no’.
In our professional lives, we’re trained to seek out our solutions for the ‘leaky faucets’ and typically only bring in an expert when we encounter a major problem that we can’t live with. For credit unions, the ‘water heater’ problems are typically the front office, as they live and die by the member experience. Having the right technology and interface (along with a myriad of other things) tends to be the core focus when it comes to investing in process and technology improvements.
Where are the ‘leaky faucets’ usually located? The back office. Temporary workarounds are created and then become standard practice; these workarounds are largely unknown to the broader organization, time-consuming, and surprisingly easy to correct. They add up and lead to frustrations and inefficiencies, just like my family experienced with our sink. I recently sat down with Mike Lawson of CU Broadcast and John Wyatt, CIO of Apple Federal Credit Union, to discuss the value of a back-office assessment.
You can check out a clip of that conversation here:
To see the entire segment, click here (just scroll down to the bottom of the page). I enjoyed speaking with Mike and John and encourage everyone in the credit union arena to subscribe to CU Broadcast if you haven’t already – it’s a great show, and one I’ve enjoyed for years.
So, when is the last time you checked your faucets? We’d love to hear from you – reach out to me if you have questions or want to learn more about maximizing your back-office efficiency.
In reading about all the FinTech lenders that have been re-imagining the customer digital journey, if you were an outsider (or a PE investor? ), you’d be left thinking that the banks and credit unions were all customer-journey challenged elephants destined to lose customers. Elephants, who are sitting on their hands, even though they oftentimes have better rates. But this is far from true. “Online-oriented” banks and credit unions have an ever-strengthening hand that they are playing. They are providing their customers and members with the service they’re looking for while outrunning the fintech models by improving their customer experience, but also leveraging their sophisticated call center capabilities. Here are two examples:
My dear 80-year-old mother, my iPhone-using, cross-country skiing mother, recently got a talking to from her son about how much more interest she could garner by moving her savings from a local brick-and-mortar-focused bank into an online outfit. We found that her interest rate would go from 0.5% to 4.0% instantly – it adds up. Easy right? We fired up the iPad on Sunday morning and got her started in opening an account at one of the leading online banks that you’ve undoubtedly heard of. But no! She didn’t pass the onboarding identity check as they couldn’t verify her existence and would need to wait to hear from a rep. Crazy right? In my Gen X point of view, I was furious and impatient, “what do you mean it can’t be done instantaneously?!”. Then again, I should have tempered this with the understanding that she hasn’t needed consumer credit since the 80s. Much to my surprise, come Monday after I had returned home contemplating how hard it would be to act as ‘remote support’ for her ongoing digital journey, my mom was called by “a nice woman,” who walked her through the process and <boom> the online bank now has a significant, sticky, new online customer that is quite pleased with their rates.
What would a fintech mantra have called for? I’d bet a paycheck they’d respond only to those that made it through the digital native process. Before you think of that as ‘the cream of the crop strategy’, what percentage of society is that really? And does that percentage have as much money to put into an online savings account as the older generation? On the surface, her new online bank seems to care more about her making a bit of money on her money than… dare I say it… her hometown bank. By combining technology and training staff on end-to-end processes (this was not that call center agent’s first rodeo), the elephant can dance. The whole experience was a real surprise to me.
In another example, at a large online-oriented credit union client of ours, I got a front-row seat of the customer journey from the other side of the fence. I had the pleasure of meeting the heads of open banking, customer journey, and customer interaction at a holiday luncheon. Those groups don’t all talk together about end-to-end journeys that often. While open banking at first is perceived as “allowing our members to provide access to their personal financial data to others,” it is now being understood as an opportunity to initiate the customer journey. A journey to keep a member from being pulled into the fintech journey, where the rate is much worse than the credit union can provide! In this case, the online credit union is working to establish a small set of predictive features from the open banking request that will trigger outreach to the member, highlighting the basics of the credit union’s competing offer (as in we think you are shopping for a personal loan; our rates are highly competitive, and we can approve you in 5 minutes…). It’s not hard to imagine the Elephant moving to a more sophisticated dance (let’s call it a ‘cha-cha-cha’) by running a soft inquiry and providing a firm offer of credit, but I suggest that a timely, but basic, triggered communication will start to become very common. And, in most cases, it’s good enough.
Execution is the hardest part of any plan, and the team at CC Pace excels at helping to turn strategy into results. Give us a call or reach out to me on LinkedIn to explore the ways we can help you tap into a more efficient customer journey process. We know your elephant can dance, and we can help.
Laid Off are words that carry a huge amount of uncertainty. The current economic situation in the U.S. is impacting a wide variety of industries, leaving many individuals unemployed and asking, what do I do now?
Coping with the emotions that come with the news of being laid off is hard and can make it difficult for you to focus on the details of what to address at that moment. This article You’ve Been Laid Off, Now What? Here are 3 steps to take if you lose your job, details some important items as to how you can protect yourself financially. In addition, as you begin your journey to finding your next career opportunity, check out CC Pace’s job postings and connect with our consultative recruiting team to see how they can be of help to you in your search.
With the World Cup taking over the headlines, we couldn’t miss an opportunity to bring two of our favorite topics at CC Pace together: sports and Agile. As Team USA gears up to take on the Netherlands, here’s a little history on the unique style of soccer the Dutch created and what Agile teams can learn from their success.
In the 1970s, the Dutch dominated their international counterparts by using a style of soccer they called totaalvoetbal or total football. Total football requires each player on the team to be comfortable and adept enough to switch positions with any other player on the field at any time. The Dutch required the goalkeeper to remain in a fixed position, but everyone else was fluid and able to become an attacker, defender, or midfield player when the play dictated it. Whenever a player moved out of his position, they were replaced by another player. Successively, all other players on the team shifted their positions to maintain their team structure. In modern soccer, we call this collective team behavior compensatory movement. All teammates compensate and adjust to each other’s actions.
This philosophy helped create teams without points of weakness that their opponents could exploit.
Totaalvoetbal only worked because players trained to develop the skills needed to play all positions. Each player was a specialist in a certain position or role, such as striker or center defense, but was also quite competent playing other roles on the team.
In the Agile world, this can be applied to the makeup of scrum teams. Scrum teams that are self-sufficient because of their fluidity are always the most productive and dependable. If scrum teams are comprised of team members with “T-shaped” skills, then there will always be team members that can fill in for others when needed.
People with T-shaped skills have a deep level of skill and expertise in one area and a lower level of expertise across many other areas. When scrum teams are comprised of team members with T-shaped skills, it helps to ensure that all work can be completed within the team. It also means that productivity is less likely to drop when a team member is out of the office because others can roll up their sleeves and help get the job done.
Cross-training and pair programming are great ways to help develop team members with T-shaped skills. Pair programming is an Agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.
T-shaped skills are not developed by accident but rather intentionally. Careful planning and a thoughtful, proactive approach by the individual and their manager are crucial. A manager must understand the value of investing in the development of people. Cross-training, stretch assignments, training opportunities, shadowing, and pair programming are all excellent methods for developing additional skills that allow for compensatory movement and fluid teams, yet, in some ways, represent short-term reductions in individual productivity. Managers must make this short-term investment to see the long-term value and score more goals.
In a previous blog post, we covered the top 10 challenges organizations face when adopting Agile. In this article, we’ll dive deep into one of these challenges: “Inadequate management support and sponsorship.” We will explore why organizations face this challenge and what can be done to address it.
Lack of management support is one of the most widespread and yet hard-to-uncover challenges. Agile transformation requires an enterprise-wide shift in mindset and culture and this requires buy-in from all levels of the organization, otherwise, it can cause the entire effort to lose alignment.
With Agile transformations, middle management is usually caught, well, in the middle. While expected to embrace the significant amount of change they will be experiencing in their own roles and responsibilities, they are also expected to be the torchbearers and lead their teams through the transformation.
Traditional management in a non-Agile culture operates largely in a command-and-control mode. It’s how they make decisions, forecast, and get work done. Agile principles strive to decentralize some of that control in favor of building self-organized and autonomous teams. This factor directly threatens management’s perception of control and can make them feel a loss of power. The root of this problem can sometimes trace back to a poorly executed change management strategy, or lack thereof. Agile is not just a small incremental change in the way organizations plan and deliver, but a fundamentally different way altogether that requires careful planning and execution to accomplish.
Below are some of the indicators that show management is not fully aligned and supportive:
- Teams do not get enough support from management when delivery challenges manifest
- Management puts a greater emphasis on following the practices and mechanics than the mindset
- There is a lack of psychological safety in the organization
- Management overvalues Agile metrics and dashboards, leading to an increase in Agile antipatterns
- Agile coaches struggle to maintain a coach and influence teams
- Key Agile tenets get ignored in favor of the sponsor’s wishes, e.g., artificial deadlines
To prevent this issue from becoming a challenge in the first place, it is important to acknowledge and plan for it while developing the transformation strategy. Here are a few ways to address this challenge:
- Address the “why”. Organizations can prevent resistance from happening by making sure management understands the “why” behind the change. Leadership needs to invest in and sponsor education and awareness campaigns to make sure people managers understand and align with the spirit of agile and are able to effectively articulate the value expected from the transformation.
- Engage and recruit management as advocates of change: Change is hard, and advocating change requires skill. If we want our management to be those advocates, it is necessary to ensure they have the right knowledge and training to play their part. Key members of management should be strategically identified and trained for advocacy, early in the transformation.
- Answer “What’s in it for me?”. While it might be well understood that Agile helps organizations deliver value early and often, it is human nature to seek personal benefit. Ensure they get a clear understanding of their future, feel secure from a career and work-life standpoint, and are able to see the benefits they stand to receive if the transformation goes well.
- Let managers know that you have their back. Agile transformations are always full of ups and downs. And the ‘downs’ ideally should be learning opportunities. However, if management is held to their old expectations and they feel they will be penalized for failures as a result of the new delivery approach, they will be less inclined to support the transformation because of potential negative impacts. Leadership needs to understand and acknowledge how ‘fail fast’ manifests itself when using Agile, and ensure management understands that they won’t be penalized when failures do occur.
- Create a ‘Growth Roadmap’. Just like ‘what’s in it for me,’ in the short term, it is important to address long-term personal benefits. As part of change management, ensure there is a clear understanding of how people will advance in their new roles in the next 3-5-8 years, what resources they will have to gain, new knowledge and credentials to consider, and which career paths they can pursue. Leadership should explain to middle-management how to be successful in an Agile culture, and ensure they recognize and reward managers for the new behaviors they want to see in them.
There is a lot that can be discussed about this challenge, and I would love to hear more from you. Have you faced similar challenges? What did you do to address them? At CC Pace, we love to engage with the community and provide value wherever possible. Reach out, we’d love to help.
Surely, we’ve all heard about the 16 Myers-Briggs personality types identified in the workplace, and while they are useful, they are not necessarily the stuff that promotes a good laugh. We at CC Pace are all about working hard and having a bit of fun while doing it, so we thought we’d take a crack at pinpointing some of the traits that identify a few of the more common roles in the corporate world. Let’s see how many you can relate to:
If your average Coke consumption is 5 or more a day … you might be a Developer
If you think knowing binary takes someone from a “6” to a “10”… you might be a Software Engineer
If you have a retrospective for your daughter’s Kindergarten graduation … you might be a ScrumMaster
If you missed a “;” and couldn’t sleep for 2 days … you might be a Java Developer
If you can keep smiling on the outside while crying on the inside … you might be a Receptionist
If you camp in a random forest, get bitten by a Python because you couldn’t C# … you might be a Data Scientist
If bagels and donuts day at work seems like an Instagramable moment … you might work in Marketing
If the phrase “Hello from the other side, must have called a thousand times” means more to you than a line in an Adele song … you might be a Recruiter
If a large part of your day consists of fielding questions like a White House Press Secretary … you might be a COO
If your future Disney vacation is visually planned on your kitchen wall … you might be an Agile Coach
If the definition of a good day includes eliminating the idea that things work … you might be a Test Engineer
If Mad Max doesn’t come close to the amount of chaos you deal with daily … you might work in Human Resources
If you find yourself measuring the flow efficiency of the Starbucks queue … you might be a Kanban Trainer
If you jam out to the hold music while on a call with your bank … you might work in IT Support
If a year that starts in April doesn’t weird you out … you might work in Accounting
If you feel you need to follow up on yesterday’s follow-up… you might be a Project Manager
If you like your coffee hot and your calls cold … you might be in Sales/Business Development
If everybody stops the chit-chat when you login to a Zoom meeting … you might be the President
At CC Pace #MakingADifference is a big part of our culture through our corporate outreach program. This fall CC Pace hosted a Back-to-School outreach initiative to benefit Lorton Station Elementary School, located in southern Fairfax County. Lorton Station is a Title One school which is a designation for schools that serve low-income families. The federal funds Lorton Station receives as a Title One school help to provide classroom materials, clothing and additional support personnel, but often these families also need supplementary assistance.
Our Back-to-School campaign was a huge success that consisted of both CC Pacers contributions and a corporate donation. Together we were able to donate more than 350 items including clipboards, markers, folders, notebooks, pencils and much more. Dawne Ward, CC Pace’s COO dropped off the donations earlier this week to Lorton Station’s parent liaison. The school expressed how very appreciative and grateful they were for all these supplies.
Our outreach program allows our employees to take an active role in contributing to the betterment of our local communities and non-profit organizations. A big shout out to all our employees who participated in this outreach event – You get an A+ for #GivingBack!
Always in the Race, this is the Team Stallions motto! The pandemic hit in 2020, it shut down many activities worldwide including cricket. Cricket was affected at both the international and local recreational levels, so the CC Pace sponsored Stallions had to hunker down too! Luckily those days are behind us, and we can get everyone caught up on all things to do with the Stallions!
Happily, the Washington Metro Cricket League (WMCL) re-opened for the Spring 2021 season. Opening the season against a tough team, the Herndon Hawks, the Stallions got off to a fantastic start. Except for losing two games in the league stage of the season, the Stallions steamrolled into the play-off games and won every game. After a drought period of 6+ years and despite reaching the playoff stage in almost every season, in presumably the toughest division of the DMV area, the Stallions went on to win the championship!
While many would think the team should have been more than satisfied and content with their championship season, they are wrong. Not the Stallions – Always in the Race! The Fall 2021 season started with a loss, but the team never looked back and reached the play-off stage with impressive wins in the league stage. The play-off games were played with once-in-a-lifetime intensity. The quarterfinals and final games were each pushed into the last over and the Stallions prevailed. Winning the final by ONE run – lots of nerve-wracking stuff for the folks watching from the sidelines! Proudly, the Stallions won another championship! This was a historic moment as it was the first time any team had won back-to-back championships!
The Spring 2022 season started well, but the Team Stallions fell short of winning the championship. The Fall 2022 season has had a rough start, with many players having conflicts. Despite all this the Stallions have still put up some amazing fights and brought home the wins. All eyes are on the Stallions as they march onwards into the fall semi-finals – will they repeat the glory and go all the way? Only time will tell.
No matter what happens, the Stallions are no longer just a team, but more like a brand! One thing you can count on is that this team is Always in the Race!
Does your Agile Transformation feel like it is stuck in mud? Maybe it is facing one of the many challenges organizations must navigate as part of their transformation.
According to the 15th State of Agile Report the top 10 Agile Challenges (Digital ai, 2021) are:
The impact of each of these can be detrimental to any Agile Transformation. The report suggests that some organizations face many of these challenges at once. The survey notes that these results have been unchanged over several years. As we look across these top 10, we find most of them relate to the organization’s cultural aspects which means that trying to improve a team’s specific use of an Agile method like Scrum, is less important than trying to improve the overall Agile Culture of the organization.
For a different view into why Agile transformations are challenged, we find the article, How to mess up your agile transformation in seven easy (mis)steps (Handscomb et al., 2018) by a McKinsey team as yet another way to look at the challenges organizations face. The seven missteps are:
- Not having alignment on the aspiration and value of an agile transformation
- Not treating agile as a strategic priority that goes beyond pilots
- Not putting culture first over everything else
- Not investing in the talents of your people
- Not thinking through the pace and strategy for scaling up beyond pilots
- Not having a stable backbone to support agile
- Not infusing experimentation and iteration into the DNA of the organization
If your organization is facing any of these challenges, or you’ve made any of the “missteps” identified by the McKinsey team, your Agile adoption may be at a stall. If you’re experiencing multiple challenges, it may be time to get some help.
When things aren’t going well with your transformation the impacts are felt at the team and organization levels. Next, we’ll look at some of these impacts.
- Team members feel frustrated and demotivated about working in an Agile environment when they aren’t supported through the transition by managers, each other, and the culture of the organization.
- Team members are unable to deliver quality increments of work due to a lack of consistent processes and tools.
- Team deliveries are hindered by defects.
- Team members struggle to learn and implement new Agile methods, or what they learn does not stick.
- Team members don’t go beyond process and learn delivery practices to improve quality, like TDD, or DevOps.
- Team members don’t work cross-functionally and instead keep silos of expertise.
- Team members struggle to coordinate across teams to remove dependencies.
- Team members burn out due to working at an unsustainable pace.
- Team member turnover is high.
- Stakeholders don’t see the value in their participation with the Team members doing the work, hindering the team’s ability to get real-time feedback and continuously improve.
- Management fails to let the team self-organize taking away from team ownership and accountability for the work. Or even worse, they micro-manage the team, their backlog, or even how they do the work
- Teams find it difficult to release rapidly hampering innovation and increasing time to market.
- Team members aren’t engaged in learning new ways of working.
In addition to the team impacts, there are several organizational impacts that can occur.
Resolving the challenges
In looking at the data, it is imperative that organizations address these challenges head-on. If you’re seeing any of the impacts listed above, you may wonder what to do to alleviate them. One of the biggest mistakes is not incorporating change management as part of an Agile Transformation. Leadership needs to help everyone in the organization understand the new culture underlying how they all work together. It requires leaders and doers alike to learn about Agile values and behaviors. Organizations must invest in training and education at all levels so that learning becomes part of the culture. How do we expect people to become Agile if we don’t teach them what Agile really is?
“What Are the Greatest Contributors to Success When Integrating Change Management and Agile?” According to Tim Creasey (Creasey, n.d.), they are:
- Early engagement of a change manager
- Consistent communication
- Senior leader engagement
- Early wins
Regardless of the Agile Methods you are trying to implement, an organization must start with changing its organizational culture, and the best way to do this is to start with change management. All the efforts of teaching and coaching will fail without the culture change to support the new Agile ways of working. Finally, engage the entire organization, not just IT, in the adoption of Agile practices and behaviors. While a pilot team will help test out a specific Agile method, their work with other members of the organization requires everyone to understand what it means to be Agile. Agile is for everyone, not just IT. A comprehensive change management program will help ensure the entire organization becomes focused on becoming Agile.
Watch for future blogs where we delve into these challenges and what CC Pace can do to help you solve them.
Are you building the right product? Are product discovery team members sharing what they’re learning with the rest of the development team? If you’re not sure, then maybe Dual Track is for you.
So, what is Dual Track? Simply put, Dual Track is about bringing light to product discovery by focusing on generating and validating product ideas for the team’s delivery backlog. It does this by bringing the product Discovery work into visibility.
You may be thinking like me, what’s the big deal? When we practice Scrum, we have the Product Owner work with stakeholders, including UX, to build a backlog. The problem is that they often do this work in a silo and only share their stories with delivery team members at Sprint Planning. If your team sees stories for the first time at Sprint Planning, it’s too late. So, in Dual Track, we have visibility into the work the PO and the discovery team members are doing, and this work is shared on a regular cadence with the rest of the team in refinement, or through team members working together.
Dual Track is nothing new. The original idea was published in 2007 by Desiree Sy, and Marty Cagan wrote about it in 2012. While there are many instances of writings about Dual Track, Jeff Patton and Marty Cagan are two of the most well-known advocates for what Marty has coined Dual Track Scrum. In its simplest form, Dual Track provides visibility and best practices to the discovery work that must occur before a team ever sees a user story. A good article to read more by Jeff Patton can be found here.
While researching Dual Track, I found that it fits nicely with what I believe the Product Owner, Business Analyst, and UX people on the team should be doing anyway. That is working with stakeholders and the team to discover the best product. Dual Track emphasizes team engagement and focuses on not letting people work in silos. It provides guidance and structure to ensure the entire team builds the right products at the right time, together as one team. So here is one of the first things I discovered about Dual Track – the team performs as one team. Read on to see what else I discovered.
One Team, One Backlog, One set of Scrum events
According to Jeff Patton, Dual Track is “just two parts of one process”. It focuses on maximizing the value delivery of your entire team by having discovery team members working a Sprint ahead of the development (delivery) team members and including them in the work.
This approach to embracing one team is important; as Jeff Patton says, “the whole team is responsible for product outcomes, not just on-time delivery”. When we keep the entire team engaged in product discovery, the developers, and testers will have more context, and they may also surprise us in ideation with great problem solutions. Finally, not all ideas in the backlog should be implemented, and developers can help Product Owners see where ideas will be problematic.
Jeff outlines how to incorporate the product design team members into each Scrum event without disruption. The team works as one, from the Daily Standup to the Sprint Retrospective. A benefit of following a Dual Track is better engagement from developers and faster learning.
Below is a good video link I found on how to set up a single backlog in Jira for Dual Track boards that enables teams to visualize the work they are doing in the two tracks:
Progress on both tracks happens simultaneously
The Discovery Track represents teamwork through product ideation via stakeholder interviews, developing personas and stories, and market research. Once complete, the discovery team members share their findings with the rest of the team. The design team members utilize design sprints to make progress on stories for Sprint N+1, while the development team members are working on Sprint N in delivery sprints. The output from product discovery becomes the input for product delivery. At the same time, feedback from product delivery informs product discovery.
Benefits of Dual Track
The Discovery Track is always a few steps ahead of the delivery team. This approach leads to:
- Better Products – Allowing only validated product ideas into the backlog leads to better products for your customers.
- Less Wasted Time – Breaking the barrier between product design and development means the whole team better understands what they are building, reducing the back-and-forth conversations that occur.
- Lower Development Costs- Teams will not pursue product features that haven’t been validated or are well-thought-out.
Dual Track increases the odds that you will deliver high-quality products that your customers will love. It does this by bringing visibility to what Product Owners are doing to prepare for a Sprint. It requires high collaboration between the people responsible for ideation and the people responsible for development. If you decide to incorporate Dual Track and design Sprints, you’ll be in good company. Jake Knapp wrote about Google Ventures utilizing design Sprints, and now we have the likes of Uber, Slack, and Facebook embracing this way of working.
I like what I’ve read about Dual Track and hope I have piqued your curiosity. I would love to hear about your experience with Dual Track if you have tried it. Please feel free to share in the comments!
In today’s digital business landscape, businesses are looking for solutions to be more competitive. Some digital businesses have found the Scrum Framework to be that competitive edge with its foundation of empiricism. Empiricism uses knowledge based on experience to make decisions. Scrum framework empiricisms reflect in three pillars of transparency, inspection, and adaption. Scrum’s Evidence-Based Management (EBM) is an empirical approach that supports organizations in demonstrating business outcomes, organizational capabilities, and business results. In the simplest terms, the EBM helps organizations navigate through complex problems by intentional small steps and adapting through continuous feedback loops. (For more on complexity, see the Scrum Theory section of the Scrum Guide at https://www.scrumguides.org/scrum-guide.html)
Scrum’s Evidence-Based Measurement approach allows organizations to avoid traps like metrics turning into milestone deliveries or project task activities. EBM offers an opportunity for the digital organization to experiment and move to their next step to value through these areas:
Key Value Areas – Unrealized value, Current Value, Time to Market, and Ability-to-Innovate.
Let’s look at them and see if your organization might benefit from using them.
First Value Area – Current Value
What is the purpose?
The organization reflects on the current value they bring to the customers or stakeholders. It is in its current state. It is not a future state at all.
How does an organization identify it?
EBM shares this value indicating the happiness of customers, stakeholders, and employees.
It can be very simple: measure how happy the customers, stakeholders, and employees are. Is their happiness up or down? The important aspect here is to get a baseline and then, at regular intervals check-in that the current state is moving towards the desired state.
Second Value Area – Unrealized Value:
What is the purpose?
The organization reflects on what future value they could provide to their customers, stakeholders, or employees. Based on the current value, what is the difference? That difference is the potential unrealized value.
How does an organization identify it?
EBM shares this value is about understanding ALL the desired needs or future state that our customers, stakeholders, and employees would like to have to be very, very happy. It allows the organization to evaluate where finances are being expended.
Third Value Area – Time to Market:
What is the purpose?
The organization determines how quickly it can deliver something new to its customers or stakeholders.
How does an organization identify it?
EBM shares this value is about understanding how the organization does things, how the organization learns, and how quickly the organization applies what they learned.
Fourth Value Area – Ability to Innovate:
What is the purpose?
The organization determines how good they are at developing new ideas that might deliver value to meet customer needs.
How does an organization identify it?
EBM shares the ability to innovate the organization by looking for blockers and dependencies and addressing them. What are the “gotchas” that prevent customers from being happy about the delivered solution?
Gathering the information for EBM’s 4 values provides the organization with a baseline and is a great first step. However, the biggest secret to success the Scrum’s Evidence-Based Measurement guidance offers is to be intentional with small steps of change to move the needle in each of the four value areas. EBM supports using the PDCA model derived by W. Edwards Deming to accomplish this.
Deming’s approach is built on:
Plan: What is the organization trying to do? (What is the problem they are trying to solve?)
Do: What are the intentional, time-boxed steps the organization will use to solve it?
Check: What are the outcomes?
Act: If the outcomes are great, then continue with that process. If the outcomes are not as expected, what changes does the organization make?
Scrum’s EBM guidance has been applied in various industries.
In one great case study, a Real-Estate Software Provider shared that after one year of using the EBM, the company had its’ largest revenue growth in over 10 years. Its success was also reflected in its EBITDA and Net Promoter score.
This case study is only one example. Has your organization used this approach? If so, what were your results?
The sample below shares an approach that might be synthesized from the Scrum Evidence-Based Measurement.
Data science in simple terms takes large amounts of data and breaks it down to solve a problem or determine a specific pattern. Business analytics are used to evaluate data and related statistics to gain perspective on trends and interpretations for making organizational decisions.
While both data science and business analytics professionals draw insights from data using statistics and software tools, deciphering between the two can be complicated. This article does a good job describing the key differences between them and the important role each plays in the way data is analyzed.
What makes a good recruiter? Well, it depends on who you ask. I’ve been in the industry for over two decades and generally see my fellow recruiting directors answer that question one of two ways. The first answer: a high-volume recruiter – someone who can source numerous candidates quickly and move on to the next requirement. This recruiter excels at meeting goals, is generally very organized, and is a transaction-oriented individual. The second response (and the answer I firmly subscribe to) is a high-value recruiter – someone who is more focused on building strong relationships with both candidates and hiring managers than they are on transactions and numbers.
As a candidate, you don’t want your career treated like just another number, so finding a high-value recruiter is important. You want someone who can help you identify if a position is a fit for now versus the right fit based on your values and long-term career goals. If you’re wondering how to tell a high-volume recruiter from a high-value recruiter, I’ve put together some of the top attributes to look for to ensure you aren’t selling yourself short next time you’re on the job hunt.
High-Value Recruiters Get to Know YOU vs Your Resume
High-value recruiters take the time to get to know you beyond your resume. They are great listeners and pick up on the subtle details that indicate if a position is going to be a good fit for your personality, career goals, and values. The relationship-oriented recruiter is focused on your long-term aspirations and considers how those align with an opportunity versus simply submitting you for positions for which you may be qualified. For example, if you have a relatively low-risk tolerance, make sure you have a recruiter who can walk you through all the considerations that moving from a full-time employee to a contractor imposes. This sort of move is more than just a salary and benefits conversation – it requires a level of consulting that a recruiter focused on value and your long-term goals are going to be willing to have, even if it means a missed hire for them in the short term in order to ensure the best fit. A great recruiter puts the candidate before the position at all costs as they are more interested in finding the right fit for both sides.
High-Value Recruiters Have a History of Success
As a candidate, you want to work with a recruiter who has been there, done that. It’s not just about the years of experience, but it really does make a difference when you work with a recruiter who has a relationship with the client and has a history of successful hires. Don’t be afraid to ask the recruiter to reference their past success at the company you’re interested in! This will help you understand the insights your recruiter may have that you couldn’t possibly get from a job posting or even a Glassdoor review.
This is one area in which a relationship-oriented recruiter will add value to your job search in more ways than you may imagine. For example, what does the recruiter know about the company culture that you don’t know? They have relationships with candidates who work there, so they have a clear sense of what it’s like to work for the client and can accurately describe the company culture, projects, and expectations. They know and understand client nuances (e.g., manager personalities, team dynamics, corporate culture) and have awareness of what you need to do in order to succeed in the interview.
A high-value recruiter will not only take the time to prepare you for the interview process but will also prepare you for success once you land the job. Great recruiters are the face of the company and it’s their job to ensure that candidates walk away from the experience feeling positive about an opportunity, even if it ends up not being the right fit.
High-Value Recruiters are an Open Book
A high-value recruiter should talk to you like a good friend and tell you what you need to hear over what you want to hear. As a job seeker, you want someone who will give you candid, honest, and constructive feedback and advice before you get to the interview. You don’t want a ‘yes man’ who only tells you what you want to hear – you want someone who can help you grow and put you in the best position possible to make a great impression on the hiring manager. A stellar recruiter will be honest with you, even if it’s uncomfortable (but will always do so in a professional and helpful way). The job may be out of your league or the money you desire may not be realistic. You may not like to hear these things, but it’s better to find them out before you get too far down the process!
High-Value Recruiters are Relationship-Oriented
Finally, one of the most important characteristics of a high-value recruiter is that they are driven by people, not numbers. You’ll know when you find them as they are laser-focused on your needs and finding out more about what drives you. They want to understand your goals, your expectations, and what job characteristics you prioritize over others. The value-driven recruiter keeps an open mind for the best long-term fit, not just the opportunity on the table.
These recruiters tend to be likable and build strong relationships with both candidates and hiring managers. There’s a level of trust on both sides, knowing that the recruiter is in it for the long haul and will go to great lengths to find the best fit for everyone because they value the relationship over a goal and would put that at stake just to get a hire. Their reputation, relationships, and referrals are more important than the instant gratification of a single transaction.
A high-value recruiter can make all the difference in your job search. When you find a recruiter who values the person over the transaction, they act like a consultant to your hiring process – advising you, redirecting you, and making sure you’re landing in the right place where you’ll be happy, have alignment with your career goals and are getting the best compensation possible.
One final piece of advice: when you find high-value recruiters, make sure you stay in touch with them, even after you have found the job because those connections can be invaluable to your career. If you have any questions about the recruiting process, feel free to connect with one of our recruiters today to see how we can help you find your next position!
Over the past several years, I’ve worked with many organizations as an Agile Coach and Scrum Master. Through this experience, I’ve noticed there is often misunderstanding at varying levels within the organization around the difference between Agile Adoption and Agile Transformation.
My goal through this blog will be to share my thoughts around Adoption and Transformation and to articulate the basic differences.
First, let me start by defining what I mean by Adoption and Transformation. We find that many organizations think they are Agile when they adopt different Agile practices and begin to check these boxes daily, like having a Daily Standup, working in Sprints, or creating a Kanban board. Organizations may see some benefit in the early stages of a Transformation when Adoption is on the uptake; however, Adoption is just one of the factors that will help a Transformation be successful. A Transformation is about more than adopting a methodology and checking a box. A Transformation changes how the entire organization behaves; it changes the organization’s culture. This change may include aligning along value streams to create virtual teams focused on the same outcome delivery. And it should also involve getting business partners to engage with the IT delivery teams to provide regular input and feedback on the work. And Transformations may see new ways of budgeting around product delivery rather than project delivery. The bottom line is that an Agile transformation is about more than having teams adopt an Agile method.
Before we dive deeper into the differences between Agile Adoption and transformation, let me draw your attention to the 15th Annual State of Agile Report on company experience in practicing Agile.
The Annual State of Agile Report is the longest continuous annual survey of Agile techniques and practices as identified by over 1300 global respondents.
Most of the respondents report their company has been practicing Agile. Quite clearly, Agile is the new buzzword, and corporations want to ensure that they don’t miss the bus. Many think it’s a plug-and-play kind of solution, and things improve overnight. It IS NOT!!
But what really is Agile Adoption, and how is it different from Agile Transformation?
In simple terms, Agile Adoption is changing the way a team does the work, whereas an Agile Transformation deals with changing the way an organization gets the work done. It’s about Doing Agile vs. Being Agile.
Sounds interesting?? Look at the 5 key differences as illustrated by Anthony Mersino.
- Speed of Change
Adoption can be quick and even measured in days or weeks. After a day or two of training, teams can agree on a tool, set up their board and events, and start following an Agile method like Scrum. I would refer to it as kind of a jumpstart. Transformations, on the other hand, can only be measured in years since the goal is about continuous improvement and cultural changes. In my previous blog, I defined the different levels and timelines as to when an organization can be transformed. While organizations might see Agile Adoption happen quickly, culture change across the organization is needed for a Transformation. And without question, culture change takes longer to come to fruition than team Adoption.
- Planning Timeframe
Agile Adoptions can be short—as the speed of change is quick compared to Transformations. Projects are temporary; thus, teams on projects can switch from Waterfall to Agile methodologies and be seen as adopting Agile. The planning timeframe for getting teams to adopt Agile can be short since we are simply changing how people work. Transformations, however, require long-standing and stable, Agile teams that take time to build. As you plan your Agile Transformation, the timeframe is much longer than that of simple Adoption, and it should include learning opportunities for everyone in the organization around the Agile mindset and how Agile organizations work differently. Change Management plays heavily in a Transformation plan.
- Productivity Gain
Researchers show a gain between 20% – 100% when it comes to Agile Adoption. In other words, just by teams following simple steps such as the PO setting priorities, focusing on a prioritized backlog, teams working together cross-functionally, etc., an organization will see gains in productivity. However, in a Transformation, one of the most significant benefits comes from developing T-shaped skills to become a cross-functional team. Transformation is more about empowering employees by encouraging them to be creative, understanding and accepting risks, and negating management layers allowing for more transparency. As an organization transforms, they decentralize decision making, advocate for innovation, focus on team outcomes over individual performance, engage business partners more readily, to name a few, and thus as a whole, may experience a productivity gain of close to 300%.
- Org Structure Change
Minimal-to-no structural change is required while a team adopts Agile methodologies. A Team of employees from different functional areas can come together to complete a project and may even move back to previous projects post completion. While together, they practice and adopt Agile methods. However, there can be chances of teams working in silos which can lead to significant inefficiencies. Team members reporting to different managers and having multiple hierarchies within a team can even delay decision-making.
Agile Transformation can have a significant impact on the organization. In a Transformation, the focus is on shifting from functional silos to more long-standing cross-functional stable teams, thereby reducing inefficiencies. While the reporting structure can remain matrixed, the team bond comes first in a Transformation. People managers in a Transformation shift their focus to employee enablement and engagement and less on directing daily work.
- Change in Culture
Have you ever heard the saying, “Culture eats strategy for breakfast?” As Adoption focuses on changing the way the team accomplishes work, a culture change may be seen solely within the group. One or more teams adopting Agile can lead to a Transformation, but it is unlikely to impact the culture significantly. When an organization sees the value from a team’s Adoption of Agile principles and practices, it may pave the way for a greater Transformation. I recommend engaging with a change management expert to help the organization’s culture change. This culture change is key to a Transformation and will bring customer satisfaction and respect for people.
In summary, both Agile Adoption and Transformations will bring value to your organization.
It all depends on the organization as to what path they follow; there isn’t a right or wrong here. I’m a strong believer that anything, when done the right way, will yield results. Its more about the process and believing in the process. What I think we can see here is that while organizations can derive value from an Agile Adoption, the true benefits come from the longer Agile Transformation.
What is the bottom line? Adoption is fast and easy, while Transformations take longer and require more planning and culture change, but without question, the benefits are worth it.
PI planning is considered the heartbeat of Scaled Programs. It is a high-visibility event, that takes up considerable resources (and yes, people too). It is critical for organizations to realize the value of PI planning, otherwise, leadership tends to lose patience and gives up on the approach, leading to the organization sliding back on their SAFe Agile journey. There are many reasons PI planning can fall short of achieving its intended outcome. For the purposes of quick readability, I will limit the scope of this post to the following 5 reasons which I have found to have the most adverse effect.
- Insufficient preparation
- Inviting only a subset (team leads)
- Lack of focus on dependencies
- Risks not addressed effectively
- Not leaving a buffer
Let’s do a deeper dive and try to understand how each of the above anti-patterns in the SAFe implementation can impact PI planning.
Insufficient Preparation: By preparation, I don’t mean the event logistics and the preparation that goes along with it. The logistics are very important, but I am focusing on the content side of it. Often, the Product Owner and team members are entirely focused on current PI work, putting out fires, and scrambling to deliver on the PI commitments, so much so that even thinking about a future PI seems like an ineffective use of time. When that happens, teams often learn about the PI scope almost on the day of PI planning, or a few days before, which is not enough time to digest the information and provide meaningful input. PI planning should be an event for people from different teams/programs to come together and collaboratively create a plan for the PI. To do that, participants need to know what they are preparing for and have time to analyze it so when they come to the table to plan, the discussions are not impeded by questions that require analysis. Specifically, this means, that teams should know well in advance, what are the top 10 features that teams should prioritize, what is the acceptance criteria, and which teams will be involved in delivering those features. This gives the involved teams a runway to analyze the features, iron out any unknowns, and come to the table ready to have a discussion that leads to a realistic plan.
Inviting only a subset: As I said in the beginning, PI planning is a high-cost event. Many leaders see it as a waste of resources and choose to only include team leads/SMs/POs/Tech Leads/Architects and managers in the planning. This is more common than you might think. It might seem obvious why this is not a good practice, but let’s do a deep dive to make sure we are on the same page. The underlying assumption behind inviting a subset of people is that the invitees are experts in their field and can analyze, estimate, plan, and commit to the work with high accuracy. What’s missing from that assumption is, that they are committing on behalf of someone else (teams that are actually going to perform the work) with entirely different skill levels, understanding of the systems, organizational processes, and people. The big gap that emerges from this approach to planning is that work that is analyzed by a subset of folks tends not to account for quite a few complexities in the implementation, and the estimate is often based on the expert’s own assessment of effort. Teams do not feel ownership of the work, because they didn’t plan for or commit to it, and eventually the delivery turns into a constant battle of sticking to the plan and putting out fires.
Lack of focus on dependencies: The primary focus of PI planning should be the coordination and collaboration between teams/programs. Effectively identifying the dependencies that exist between teams and proper collaboration to resolve them is a major part of the planning event to achieve a plan with higher accuracy. However, teams sometimes don’t prioritize dependency management high enough and focus more on doing team-level planning, writing stories, estimating, adding them to the backlog, and slotting them for sprints. The dependencies are communicated, but the upstream and downstream teams don’t have enough time to actually analyze and assess the dependency and make commitments with confidence. The result is a PI plan with dependencies communicated to respective teams but not fully committed. Or even worse, some of the dependencies are missed only to be identified later in the PI when the team takes up the work. A mature ART prioritizes dependencies and uses a shift-left approach to begin conversations, capture dependencies, and give ample time to teams to analyze and plan for meeting them.
Risks not addressed effectively: During PI planning, the primary goal of program leadership should be to actively seek and resolve risks. I will acknowledge that most leaders do try to resolve the risks, but when teams bring up risks that require tough decisions, change in prioritization, and a hard conversation with a stakeholder, program leadership is not swift to act and make it happen. The risk gets “owned” by someone who will have follow-up action items to set up meetings to talk about it. This might seem like the right approach, but it ends up hurting the teams that are spending so much time and effort to come up with a reasonable plan for the PI. There is nothing wrong with “owning” the risks and acting on them in due time, however, during PI planning, time is of the essence. A risk that is not resolved right away, can lead to plans based on assumptions. If the resolution, which happens at a later date/time, turns out to be different from the original assumption made by the team, it can lead to changes in the plan and usually ends up putting more work on the team’s plate. The goal should be to completely “resolve” as many risks as possible during planning, and not avoid tough conversations/decisions necessary to make it happen.
Not leaving a buffer: We all know that trying to maximize utilization is not a good practice. Most leaders encourage teams to leave a buffer during the planning context on the first day. But, in practice, most teams have more in the backlog than they can accomplish in a PI. During the 2 days of planning, it is usually a battle to fit as much work as possible to make the stakeholders happy. For programs that are just starting to use SAFe, even the IP sprint gets eaten up by planned feature development work. One of the root causes for this is having a false sense of accuracy in the plan. Teams tend to forget that this is a plan for about 5 to 6 sprints that span over a quarter. A 1 sprint plan can be expected to have a higher level of accuracy because of a shorter timebox, less scope, and more refined stories. However, when a program of more than 50 people (sometimes close to 150 people) plans for a scope full of interdependencies, expecting the same level of accuracy is a recipe for failure. In order to make sure the plan is realistic, teams should leave the needed buffer and allow teams to adjust course when changes occur.
As I mentioned at the start of this post, there are many ways a high-stakes event like PI planning can fail to achieve the intended outcomes. These are just the ones I have experienced first-hand. I would love to know your thoughts and hear about some of the anti-patterns that affected your PI Planning and how you went about addressing them.
CC Pacers volunteered with the Middleburg Humane Foundation (MHF) at their K9’s in the Vines event last week located at The Winery at La Grange in Haymarket, Virginia. MHF operates a non-profit, 23-acre farm-shelter located in Marshall, Virginia. They rescue, rehabilitate, and adopt at-risk animals and promote animal welfare through community outreach and humane education. Last year alone, MHF rescued 783 cats, dogs, equines, livestock, pocket pets, and reptiles. Take a look at their adoption site for a full up-to-date list of adoptable animals! From puppies to pigs and beyond, MHF rescue and adopt them all!
Volunteering on what was an absolutely beautiful day, we had the opportunity to bring 3 puppies and 2 adult dogs to MHF’s promotional K9’s in the Vines event. As volunteers we spent a few hours walking the dogs around the scenic property, speaking with patrons, and promoting the organization –it was a BLAST! In addition to the in-person event, CC Pacers also donated dog toys, supplies for the shelter, and money directly to MHF.
Interested in becoming a hands-on volunteer with the Middleburg Humane Foundation? Check out their volunteer site for more ways to get involved.
How do you move forward as an organization to achieve your vision? What’s working well? What’s holding you back or bogging things down? As a mortgage consultant who’s worked in the industry for years, I hear these questions all the time from organizational leaders. And there is help! One tool that’s very effective in helping you answer these challenging questions is an Operational Assessment. Operational Assessments are a pulse check for your business. Every company can benefit from an operational assessment; it provides an open, honest, and objective viewpoint of your business’s current processes, procedures, technology, people, and risks. And once you have this information, you’ll be able to create a plan and chart a path for the future.
So how do you get started on an operational assessment? Where do you find the information? Again, the operational assessment is to provide a checkup of your organization. There is no better way to get to the truth than talking with your employees and clients.
Most Operational Assessments include the following components, so you’ll want to frame your questions and surveys around these business areas.
So, what’s the best approach to collecting data? Staff interviews and ride-a-longs are a great option, and it is through these conversations with employees that you’ll gather a lot of information to complete the assessment. Listen carefully. Because without question, you’ll gain tremendous insight into the formal and informal processes and cultural norms that drive the business. For example, does the current technology effectively support the business? Does it help employees complete their jobs, or is it a constant issue? Are leaders delivering a consistent message, uniting around common goals and direction? In short, are we all together in the boat rowing in the same direction? People are the core of the business, and it’s important to understand their feedback, comments, perspectives, and observations. Through open dialogue, you’ll uncover things that are not always seen, like workarounds, completing work in a strange order, missing key items that could make reporting better, outdated policies and procedures, etc.
For external customers, consider using interviews, or to reach a broader audience, surveys are also very effective. Do customers have a positive experience when engaging with your organization? Are they satisfied with the business relationships? You’ll want to incorporate feedback from closed and unclosed loan clients, as well as your realtor/builder partners.
An operational assessment is only as good as the honest and open feedback received, a clear view into the company’s current operations, AND leadership that is willing to listen, then adjust and apply any apt learnings.
This blog is a very brief overview of an operational assessment that could help you objectively determine the status of your organization. Once you can see things with complete transparency, it can help define intentional growth or organizational change steps. Once you know where you are, THAT VALUE can help you get where you want to be.
Are you new to Agile testing?
I’ve been reading Agile Testing, by Lisa Crispin and Janet Gregory. If you are new to Agile testing, this book is for you. It provides a comprehensive guide for any organization moving from waterfall to Agile testing practices. The “Key Success Factors” outlined in the book are important when implementing Agile testing practices, and I would like to share them with you.
Success Factor 1: Use the Whole Team Approach
Success Factor 2: Adopt an Agile Testing Mind-Set
Success Factor 3: Automate Regression Testing
Success Factor 4: Provide and Obtain Feedback
Success Factor 5: Build a Foundation of Core Practices
Success Factor 6: Collaborate with Customers
Success Factor 7: Look at the big picture
Success Factor 1: Use the Whole Team Approach
In Agile, we like to take a team approach to testing. Developers are just as responsible for the quality of a product as any tester; they embrace practices like Test-Driven Development (TDD) and ensure good Unit testing is in place before moving code to test. Agile Testers participate in the refinement process, helping Product Owners write better User Stories by asking powerful questions and adding test scenarios to stories. Everyone works together to build quality into the product development process. This approach is very different from a waterfall environment where the QA/Test team is responsible for ensuring quality software/products are delivered.
Success Factor 2: Adopt an Agile Testing Mind-Set
Adopting Agile starts with changing how we think about the work and embracing Agile Values and Principles. In addition to the Agile Manifesto’s 12 Principles, Lisa and Janet define 10 Principles for Agile Testing. Testers adopt and demonstrate an Agile testing mindset by keeping these principles top of mind. They ask, “How can we do a better job of delivering real value?”
10 Principles for Agile Testing
- Provide Continuous Feedback
- Deliver Value to the Customer
- Enable Face-to-Face Communication
- Have Courage
- Keep it Simple
- Practice Continuous Improvement
- Respond to Change
- Focus on People
Success Factor 3: Automate Regression Testing
Automate tests where you can and continuously improve. As seen in the Agile Testing Quadrants, automation is an essential part of the process. If you’re not automating Regression tests, you’re wasting valuable time on Manual testing, which could be beneficial elsewhere. Test automation is a team effort, start small and experiment.
Success Factor 4: Provide and Obtain Feedback
Testers provide a lot of feedback, from the beginning of refinement through to testing acceptance. But keep in mind – feedback is a two-way street, and testers should be encouraged to ask for their own feedback. There are two groups where testers should look for feedback. The first is from the developers. Ask them for feedback about the test cases you are writing. Test cases should inform development, so they need to make sense to the developers. A second place to get feedback is from the PO or customer. Ask them if your tests cover the acceptance criteria satisfactorily and confirm you’re meeting their expectations around quality.
Success Factor 5: Build a Foundation of Core Practices
The following core practices are integral to Agile development.
- Continuous Integration: One of the first priorities is to have automated builds that happen at least daily.
- Test Environments: Every team needs a proper test environment to deploy to where all automated and manual tests can be run.
- Manage Technical Debt: Don’t let technical debt get away from you; instead make it part of every iteration.
- Working Incrementally: Don’t be tempted to take on large stories; instead break down the work into small stories and test incrementally.
- Coding and Testing Are Part of One Process: Testers write tests, and developers write code to make the test pass.
- Synergy between Practices: Incorporating any one practice will get you started. A combination of these practices, which to work together, is needed to gain the advantage of Agile development fully.
Success Factor 6: Collaborate with Customers
Collaboration is key, and it isn’t just with the developers. Collaboration with Product Owners and customers helps clarify the acceptance criteria. Testers make good collaborators as they understand the business domain and can speak technically. The “Power of Three” is an important concept – developers, testers, and a business representative form a powerful triad. When we work to understand what our customers value, we include them to answer our questions and clear up misunderstandings; then, we are truly collaborating to deliver value.
Success Factor 7: Look at the Big Picture
The big picture is important for the entire team. Developers may focus on the implementation details, while testers and the Product Owners have the view into the big picture. Aside from sharing the big picture with the team, the four quadrants can help you to guide development so developers don’t miss anything.
In addition, you’ll want to ensure your test environments are as similar as possible to production. Test with production-like data to make the test as close to the real world as possible. Help developers take a step back and see the big picture.
At the end of the day, developers and testers form a strong partnership. They both have their area of expertise. However, the entire team is the first line of defense against poor quality. The focus is not on how many defects are found; the focus is on delivering real value after each iteration.
LinkedIn is the #1 business networking channel right at your fingertips and is a must in the virtual world we are living in today. The love affair that CC Pace has with LinkedIn grows each day because it offers users so much each time you log in.
LinkedIn makes it so easy to follow colleagues, companies, and influencers to learn about new topics, industries, and brands daily. You can find a new career opportunity, reconnect with an old colleague, or learn about all the latest and greatest business news instantaneously. Looking for others who share your professional passion, no problem, simply join a LinkedIn Group featuring others who want to share their knowledge and know-how in that area. We could go on and on with our list, so we narrowed it down to share the Top 5 Things CC Pace Loves about LinkedIn:
Did you know that by spending just 5 minutes a day on LinkedIn you can easily stay relevant and connected – how great is that? We are curious what it is that you love about LinkedIn, take a moment, and please share with us what you enjoy most from this network? And, while you are logged in be sure to connect with CC Pace on LinkedIn.
When I was first introduced to Agile development, it felt like a natural flow for developers and business stakeholders to collaborate and deliver functionality in short iterations. It was rewarding (and sometimes disappointing) to demo features every two weeks and get direct feedback from users. Continuous Integration tools matured to make the delivery process more automated and consistent. However, the operations team was left out of this process. Environment provisioning, maintenance, exception handling, performance monitoring, security – all these aspects were typically deprioritized in favor of keeping the feature release cadence. The DevOps/DevSecOps movement emerged as a cultural and technical answer to this dilemma, advocating for a much closer relationship between development and operations teams.
Today, companies are rapidly expanding their cloud infrastructure footprint. What I’ve heard from discussions with customers is that the business value driven by the cloud is simply too great to ignore. However, much like the relationship between development and ops teams during the early Agile days, a gap is forming between Finance and DevOps teams. Traditional infrastructure budgeting and planning doesn’t work when you’re moving from a CapEx to OpEx cost structure. Engineering teams can provision virtually unlimited cloud resources to build solutions, but cost accountability is largely ignored. Call it the pandemic cloud spend hangover.
Our customers see the flexibility of the cloud as an innovation driver rather than simply an expense. But they still need to understand the true value of their cloud spend – which products or systems are operating efficiently? Which ones are wasting resources?
I decided to look into FinOps practices to discover techniques for optimizing cloud spend. I researched the FinOps Foundation and read the book, Cloud FinOps. Much like the DevOps movement, FinOps seeks to bring cross-functional teams together before cloud spend gets out of hand. It encompasses both cultural and technical approaches.
Here are some questions that I had before and the answers that I discovered from my research:
Where do companies start with FinOps without getting overwhelmed by yet another oversight process?
Start by understanding where your costs are allocated. Understand how the cloud provider’s billing details are laid out and seek to apply the correct costs to a business unit or project team. Resource tagging is an essential first step to allocating costs. The FinOps team should work together to come up with standard tagging guidelines.
Don’t assume the primary goal is cost savings. Instead, approach FinOps as a way to optimize cloud usage to meet your business objectives. Encourage reps from engineering and finance to work together to define objectives and key results (OKRs). These objectives may be different for each team/project and should be considered when making cloud optimization recommendations. For example, if one team’s objective is time-to-market, then costs may spike as they strive to beat the competition.
What are some common tagging/allocation strategies?
Cloud vendors provide granular cost data down to the millisecond of usage. For example, AWS Lambda recently went from rounding to the nearest 100ms of duration to the nearest millisecond. However, it’s difficult to determine what teams/projects/initiatives are using which resources and for how long. For this reason, tagging and cost allocation are essential to FinOps.
According to the book, there are generally two approaches for cost allocation:
- Tagging – these are resource-level labels that provide the most granularity.
- Hierarchy-based – these are at the cloud account or subscription-level. For example, using separate AWS accounts for prod/dev/test environments or different business units.
Their recommendation is to start with hierarchy-based allocations to ensure the highest level of coverage. Tagging is often overlooked or forgotten by engineering teams, leading to unallocated resources. This doesn’t suggest skipping tags, but make sure you have a consistent strategy for tagging resources to set team expectations.
How do you adopt a FinOps approach without disrupting the development team and slowing down their progress?
The nature of usage-based cloud resources puts spending responsibility on the engineering team since inefficient use can affect the bottom line. This is yet another responsibility that “shifts left”, or earlier in the development process. In addition to shifting left on security/testing/deployment/etc., engineering is now expected to monitor their cloud usage. How can FinOps alleviate some of this pressure so developers can focus on innovation?
Again, collaboration is key. Demands to reduce cloud spend cannot be a one-way conversation. A key theme in the book is to centralize rate reduction and decentralize usage reduction (cost avoidance).
- Engineering teams understand their resource needs so they’re responsible for finding and reducing wasted/unused resources (i.e., decentralized).
- Rate reduction techniques like using reserved instances and committed use discounts are best handled by a centralized FinOps team. This team takes a comprehensive view of cloud spend across the organization and can identify common resources where reservations make sense.
Usage reduction opportunities, such as right sizing or shutting down unused resources, should be identified by the FinOps team and provided to the engineering teams. These suggestions become technical debt and are prioritized along with other work in the backlog. Quantifying the potential savings of a suggestion allows the team to determine if it’s worth spending the engineering hours on the change.
How do you account for cloud resources that are shared among many different teams?
Allocating cloud spend to specific teams or projects based on tagging ensures that costs are distributed fairly and accurately. But what about shared costs like support charges? The book provides three examples for splitting these costs:
- Proportional – Distribute proportionally based on each team’s actual cloud spend. The more you spend, the higher the allocation of support and other shared costs. This is the recommended approach for most organizations.
- Evenly – split evenly among teams.
- Fixed – Pre-determined fixed percentage for each team.
Overall, I thought the authors did a great job of introducing Cloud FinOps without overwhelming the reader with another rigid set of practices. They encourage the Crawl/Walk/Run approach to get teams started on understanding their cloud spend and where they can make incremental improvements. I had some initial concerns about FinOps bogging down the productivity and innovation coming from engineering teams. But the advice from practitioners is to provide data to inform engineering about upward trends and cost anomalies. Teams can then make decisions on where to reduce usage or apply for discounts.
The cloud providers are constantly changing, introducing new services and cost models. FinOps practices must also evolve. I recommend checking out the Cloud FinOps book and the related FinOps Foundation website for up-to-date practices.
Banking is continually evolving, and lately, I’ve been reading a lot about the need for community banks to embrace digital transformation. How do Community Banks create an omnichannel model while maintaining their hometown appeal? As I was thinking about this question and the growing call for change, it made me reflect on the community bank that was central to the small town where I grew up. This brought back a lot of nostalgia and memories that I wanted to share about my community bank’s role in my life.
I grew up in Damascus, a small town in Montgomery County, Maryland. Our local bank, Damascus Community Bank, opened when I was a sophomore in high school by two pillars in the local community, and it grew very quickly. In a short amount of time, the bank had six locations. It was instrumental in supporting many local businesses, and also offered programs to teach kids about savings and checking. In Damascus, it was the “Cheers” of banking; everyone knew your name. And, of course, lollipops were plentiful!
Although my high school was part of a wealthy county, our athletic facilities were dated, and we were last on the list to have lights installed on our football field. Friday night football games were the social glue of a small town back then. Football games were where everyone would catch up after a long week before going to the bank Saturday morning. Unfortunately for the Damascus community, “Friday Night Lights” didn’t exist because of a funding issue. While the community frequently petitioned the county for assistance, they only offered a portion of the required funding. But when Damascus Community Bank opened, they set a plan in motion to help us raise the money necessary to close the gap so we could finally get lights for our football field and have Friday night games. This commitment to the community is still visible today; the lights are still on every Friday night. This local support was second nature for Damascus Community Bank and allowed them to become fully entrenched and accepted as a vital part of the community.
When I graduated high school, I needed a reliable car to drive back and forth to college. I didn’t have much money saved, so the first place I turned to for help was Damascus Community Bank. I knew the loan officer well; they had helped me open my first checking account. So, when I needed a car loan, they sat down with me to explain how much I could borrow, my monthly payments, and approved me for my first loan, even though I had no credit. At this point, I still hadn’t found a car to buy, but I had the loan to get the process started. Eventually, I found a great Burgundy Chrysler LeBaron, just what every 18-year-old girl dreams of driving. But there was an issue. The down payment I needed was not covered in my approved loan amount. When I went back to the bank, they agreed to issue another loan for half of the down payment. This is the result of having a personal connection with the bank and the employee who worked there.
My experience of purchasing my first car is something I will never forget. It was significant for several reasons. For starters, it was a rite of passage to become an adult; I purchased the car without any help from my parents. But secondly, it was my first experience dealing directly with a financial organization. Damascus Community Bank recognized me as a person, not just an account holder. They extended credit even though I had no history of credit yet. They were willing to take a chance on me. This type of experience doesn’t typically occur outside the community bank structure. Something I came to realize when I started dealing with larger banks.
While attending college, I needed money to cover tuition and living expenses. My job at the local garden mart was seasonal, and it just wasn’t cutting it. I decided to try banking instead, and off I went to apply for a part-time bank teller position at Damascus Community Bank. Because they knew me, I was given my very first job in a professional setting. Through this experience, I realized that I truly enjoyed serving and helping other people. Damascus Bank was the heart of the community, and every week, I would see neighbors and friends when they stopped by to cash a check or make a deposit. The bank impacted me as well as the people it served.
The Damascus Community Bank doesn’t exist today. Like so many community banks, it was acquired by a larger financial institution. When I drive back to visit my hometown, it always feels a little sad not to see the bank sign that had been there for so many years. But time marches on, and through mergers and acquisitions, community banks are being swallowed up; they are no longer the hub of the community. And I can’t help but wonder if other people miss that connection the local bank provided.
There is no question that continual enhancements with current banking technology and omnichannel banking strategies have created more services and options for customers. Change is a necessary part of growth, and today’s banks provide a vast array of services, from opening a bank account to restructuring a mortgage. These offerings provide numerous benefits and advantages. So how does a community bank progress with technology while maintaining their connection with the customers they serve? I still believe that the community bank is a vital business needed in every small town across America.
Do you have a community bank story?
Have you heard of OKRs? Is your organization considering adopting OKRs? If so, this post is for you.
OKR stands for Objectives and Key Results. Andy Grove created them while at Intel, and they’ve been growing in their use ever since. The Objective equals the “what” we will achieve, and the Key Result is the benchmark we use to measure how we are doing.
OKRs have been working for organizations like Google and Intel for years. Implementing them for your organization can help drive focus and alignment around working on the right things. While anyone can read the book Measure What Matters, by John Doerr to learn how to write OKRs, it is by following a tried-and-true implementation plan that OKRs truly help organizations achieve the desired focus.
According to Scaled OKRs, Inc. the following key steps should be included:
- Build the team
- Execute the OKR cycle
- Calibrate Regularly
- Continue to the next OKR cycle
Step 1: Build the team
Build a team to lead the implementation of OKRs. Identify a sponsor and champion. These leaders should understand how keeping OKRs visible throughout the organization will lead to success. As with any change, practicing good change management is important. Introducing OKRs is no exception. Be sure to include a change manager in your team. In addition, your team should include someone familiar with how to write OKRs to guide and mentor those new to writing them.
Step 2: Communicate
Once you have identified the team that will lead and support implementing OKRs, the next step is all about change management communications. Your first communication should occur about two months before roll-out. In your communication, be sure and answer the questions, Why OKRs? And why now? Aside from creating a sense of urgency to adopt, create a vision for the change and share it out too. Have the communication come from Leadership to show the importance of implementing OKRs. Our change manager follows the Prosci ADKAR Model. The next message should come about one month prior to the roll-out and should be the formal kick-off announcement of the OKR process. Followed shortly by sharing the company level OKRs, and training workshops schedule.
Step 3: Train
Next, you’ll need to do some training. While OKRs may seem easy to write, putting pen to paper and coming up with the right OKRs can be a daunting task. A training workshop with a writing exercise will help attendees get orientated around what makes good OKRs. Here they will learn that the objective is qualitative, and the Key Results are quantitative. You may need a train-the-trainer session to enable others to assist teams in writing their OKRs. I like to share John Doerr’s “Super Powers” of OKRS as a reminder. These include:
- Focus & commit to priorities
- Align & connect teamwork
- Track for accountability
- Stretch for amazing
Step 4: Execute the OKR Cycle
With company OKRs in hand and training underway, the next step is to start the OKR Cycle.
In this cycle, teams write and share their OKRs to ensure vertical and horizontal alignment.
The Enterprise Context grounds teams to the highest level OKRs that were developed by leadership. This gives everyone something to tie their OKRs to and sets the direction for the organization. This allows teams to work on co-creating the localized OKRs.
The OKR Cycle looks like this:
The next step is for individual teams to write their localized OKRs. When it comes to writing OKRs, one of my favorite tips for writing OKRs is that you should be able to read them in the following format:
We will achieve (objective), as measured by (Key result).
Before everyone starts writing OKRS, you may want to think about how they will be kept. If you haven’t picked a tool to manage your OKRs, writing them in a shareable manner can become difficult. It’s easy enough to share across one or two verticals and even one or two horizontals. However, the more widely your OKR implementation, the more imperative a tool becomes.
Once the teams have created their OKRs, it’s time for them to develop their “Action plan,” or backlog of epics they will use to accomplish their OKRs. As part of an action plan, identify key result owners, and the frequency of review huddles. You’ll want a regular cadence of review. This step can be done at Scrum events, like the Sprint Review. The worst thing that can happen is to write OKRs and then forget about them. Finally, identify what scoring mechanism will be used.
Around the second month of the OKR cycle, check-ins and scoring occur. Many organizations follow Google’s lead when it comes to scoring. In their system, 0 is a failure, and 1 is a success. Here is a view of what the scores look like:
You can see from this scale that a .7 is green. It is considered a success. This is especially true for OKRs that are ambitious and represent a real stretch for the team. A team that consistently gets a 1.0 could be considered as not creating ambitious enough OKRs.
In the timeline above, we allocated four weeks to work on the first set of OKRs and two weeks for subsequent quarters. The first draft of OKRs tends to take the longest. Be sure and allocate plenty of time for creating your first set of OKRs.
One last comment about this cycle, tracking and sharing progress is an ongoing effort. All-hands meetings are great places to talk about progress. This will keep them from being just another goal-setting activity and keeps them at the forefront of everyone’s work plans.
Step 5: Calibration
Calibration reviews should happen quarterly. This is where you gather the data and identify if anything has changed before we move on to creating our next quarter’s OKRs. Calibration is a great time to do a retrospective on the OKRs. It is also a good time to ask questions like has the company level OKR’s changed? Before you start a new quarter of OKRs, calibrate where you ended on the current quarter and what, if anything, do you need to update or change before writing new OKRs for the upcoming quarter.
Step 6: Continue to the next OKR cycle
Repeat Steps 4 and 5 as part of your ongoing OKR program.
As you can see, rolling out a successful OKR program takes a bit of effort, but it is well worth it. When you incorporate your OKR roll-out into a program that is well planned, you are sure to get the entire organization on board. Once in place, you can use your OKRs to measure the outcomes the organization is striving to achieve, and everyone will be aligned. You can use your OKRs to determine the right things to be working on and say no to things that don’t align with your OKRs. With a good tool, everyone can see how their work aligns with the big picture. Regular check-ins give you the opportunity to see ongoing progress or make course corrections. Most importantly, your organization will be on the path to measuring progress towards desirable outcomes. If you have questions or want to know more, just reach out to me: email@example.com
If we asked you to list the three best parts of your job, most of you would have the relationships you have formed with your co-workers on that short list. The people who are by your side each day, (yes, even remote they are just a quick Teams call away), the ones who you collaborate with and work closely with day in and day out. At CC Pace we say, our people are our most important asset, so what better way to instill that than creating a peer-to-peer recognition program!
The CC Pace Superior Performance Award (SPA) is an award meant for CC Pacer’s to recognize fellow employees for their significant and lasting impact on CC Pace. This nomination platform allows employees across the board to acknowledge their peers’ accomplishments and call out their outstanding contributions. We are happy to announce the winners of the inaugural SPAs, congratulations to Jannette Brace and Lauren Iezzoni!
JANNETTE BRACE has stepped up to lead a new client’s Agile Transformation project that began last year. From the onset of the engagement, Jannette has demonstrated her customer relations skillset by developing a genuine trust and line of open communications with both the client’s leadership and project teams. Jannette’s leadership, exceptional consulting skills, in-depth Agile experience, and ability to build and grow client relationships have been integral to CC Pace’s recent success.
LAUREN IEZZONI routinely demonstrates her commitment to elevating our corporate branding efforts to new heights. She possesses a positive attitude and consistently produces agency-quality designs. Lauren is constantly striving to take her skills to the next level, while her contributions are highly visible and greatly received across the organization. One of Lauren’s greatest attributes is her commitment to being a team player, where she not only pushes herself to do her best but inspires that same level from those around her.
Please join us in a round of applause for these two exceptional team members!
Good Morning – Yes, it is time to brace ourselves it’s Monday, again! I think I can hear the communal groan from here. What is it about Mondays anyway? Perhaps it’s because they are the first hint of responsibility after two glorious days of fun, maybe it’s that annoying buzz at way-too-early o’clock that you haven’t heard in two days, or it’s because it marks the beginning of the week, and all beginnings are challenging at best – but Mondays sure get a bad rap. Songs such as I Don’t Like Mondays, Manic Monday, and Rainy Days and Mondays are only more proof that we all have some angst towards Mondays.
Trying to tackle a change of perspective regarding Mondays may seem like a fool’s errand but hear me out. What if, along with the not-so-positive aspects about Monday, we also consider that they provide an opportunity for a fresh start and a clean slate? The ultimate reset button if you will. Perhaps, this Monday is THE day that everything falls into place for you. Consider that trying to start the new week off with a positive outlook may be the key to unlocking your inner #MondayMotivation. At the very least, you know that the first cup of coffee tastes better on Monday morning.
Still, no? Ok well, maybe we can offer some help to get you through the 52 Mondays each year: here is a link to some Monday motivational quotes for inspiration, or how about some ways to beat the Monday blues. Opting for easy dinner ideas may be the answer to making Monday more bearable. In any case, here we are this Monday morning, so grab your coffee, open the shades, and let’s kickstart the day!
As a Senior Scrum Master, I’ve worked with many organizations, and I’m frequently asked by leaders one common question: how long will it take for my team to be Agile? The answer is never easy; developing an Agile mindset can be complex. From senior executives to developers, everyone in the organization must be open-minded and willing to change. Of course, there will always be resistance, but this can be handled through open dialogue and continual conversation.
I’d like to walk through a staged representation depending upon the maturity levels that each team goes through in becoming Agile. The information you can gather from the maturity levels is an important metric that organizations are intrigued and excited to see because they show progress in their Agile journey. I have used the maturity levels extensively with teams, and it’s always great to show progress; but remember, it’s just a tool.
So, with that being said, let’s get started. I will review each maturity level a team goes through, and along the way, I’ll share my perspective and lessons learned.
Level 1 is a Learning Phase. As teams get started on their Agile journey, it’s essential to introduce and establish an Agile mindset. From my experience, an Agile Boot Camp is a great way to create this awareness and introduce some initial concepts. It’s also an opportunity to see the team composition, make introductions, and begin a new way of working together. While Level 1 focuses on awareness, you can’t short-change the importance of this initial step; it sets the foundation for the beginning of the journey and the team’s future success.
To reach Level 2, teams must have a solid understanding of what it means to be Agile, and they must also recognize there is a difference between Agile and Scrum/Kanban. Frequently, I hear teams using words like Agile and Scrum interchangeably; and it’s important everyone understands that Agile is a methodology, whereas Scrum and Kanban are different frameworks of Agile. The Agile ceremonies or events should be scheduled with a set agenda and teams should practice story card-based requirement gathering.
Once the team has a firm grip on what it means to be Agile, they’re practicing the events, using terms correctly, and understanding the different frameworks; it’s time to move to Level 3, where the focus is on proper planning, practicing trade-offs, backlog management, and inspect/adapt principles. Better planning is your key to executing a sprint well. Having a solid backlog and adopting inspect/adapt principles will play a crucial part in a team’s success. The team should be encouraged and start to practice trade-offs.
As a Scrum Master and coach, I continually talk with my teams about embracing change. As they transition from Waterfall to Agile, the team should practice the “yes, I can, but…” phrase. For example, the Product Owner issues a new requirement, but the team already has a full plate of work. At this point, the team should be willing to practice a trade-off, accepting the requirement but be open to a conversation with the Product Owner to reprioritize existing items. Through this process, we ensure change is embraced and simultaneously practice trade-offs to not burn out the team.
As we move up the ladder, Level 4 is about the team starting to self-organize. In the planning session, there is a discussion about the sprint goals and stories, and the team should be able to self-organize and pick up the tasks that will help them achieve the sprint goal. Remember – it’s team commitment, not individual commitments, that matter. The team should be able to start measuring the process and looking at ways to improve, such as introducing some automation in the form of testing.
Level 5 focuses on improving T-Shaped skills, which can be attained by having a buddy-pair system within the team. Through this process, knowledge is gained and shared across teammates, thereby ensuring the team becomes cross-functional as time progresses. Teams will now be experienced looking at extreme automation techniques like RPA and AI, developing CI/CD pipelines, and eventually working in a DevOps model.
In conclusion, an Agile Transformation begins with a people mindset. While we looked at the Agile Transformation Maturity levels, it’s important to understand the effort put in by all players within an organization. From developers to Product Owners to Agile sponsors, everyone plays a role in achieving a successful Agile Transformation. As your organization moves through the different levels, remember, it’s going to be a bumpy ride. There will be forward momentum as well as setbacks; hence, it takes time. But as a Scrum Master who has worked with teams on their transformation journey, moving through the different maturity levels is a process, but the result is worth it.
We’ve been using the AWS Amplify toolkit to quickly build out a serverless infrastructure for one of our web apps. The services we use are IAM, Cognito, API Gateway, Lambda, and DynamoDB. We’ve found that the Amplify CLI and platform is a nice way to get us up and running. We then update the resulting CloudFormation templates as necessary for our specific needs. You can see our series of videos about our experience here.
However, starting with the Amplify CLI version 7, AWS changed the way to override Amplify-generated resource configurations in the form of CFT files. We found this out the hard way when we tried to update the generated CFT files directly. After upgrading the CLI and then calling amplify push, our changes were overridden with default values – NOT GOOD! Specifically, we wanted to add a custom attribute to our Cognito pool.
After a few frustrating hours of troubleshooting and support from AWS, we realized that the Amplify CLI tooling changed how to override Amplify-generated content. AWS announced the changes here, but unfortunately, we didn’t see the announcement or accompanying blog post.
Amplify now generates an “overrides.ts” Typescript file for you to provide your own customizations using Cloud Development Kit (CDK) constructs.
In our case, we wanted to create a Cognito custom attribute. Instead of changing the CFT directly (under the new “build” folder in Amplify), we generate an “override.ts” file using the command: “amplify override auth”. We then added our custom attribute using the CDK:
Important Note: The amplify folder structure gets changed starting with CLI version 7. To avoid deployment issues, be sure to keep your CLI version consistent between your local environment and the build settings in the AWS console. Here’s the Amplify Build Setting window in the console (note that we’re using “latest” version):
If you’re upgrading your CLI, especially to version 7, make sure to test deployments in a non-production environment, first.
What are some other uses for this updated override technique? The Amplify blog post and documentation mention examples like Cognito overrides for password policies and IAM roles for auth/unauth users. They also mention S3 overrides for bucket configurations like versioning.
For DynamoDB, we’ve found that Amplify defaults to a provisioned capacity model. There are benefits to this, but this model charges an hourly rate for consumption whether you use it or not. This is not always ideal when you’re building a greenfield app or a proof-of-concept. We used the amplify override tools to set our billing mode to On-demand or “Pay per request”. Again, this may not be ideal for your use case, but here’s the override.ts file we used:
At first, I found this new override process frustrating since it discourages direct updates to the generated CFT files. But I suppose this is a better way to abstract out your own customizations and track them separately. It’s also a good introduction to the AWS CDK, a powerful way to program your environment beyond declarative yaml files like CFT.
Further reading and references:
DynamoDB On-Demand: When, why and how to use it in your serverless applications
Authentication – Override Amplify-generated Cognito resources – AWS Amplify Docs
Override Amplify-generated backend resources using CDK | Front-End Web & Mobile (amazon.com)
Top reasons why we use AWS CDK over CloudFormation – DEV Community
Here is our final video in the 3-part series Building and Securing Serverless Apps using AWS Amplify. In case you missed Part 1 you can find it here along with Part 2 here. Please let us know if you would like to learn more about this series!
So, it was early 2009, I had been laid off and decided to relocate from Dallas to Austin. After getting established, I set out to find a job, NOT in the mortgage industry. I wanted to be more technology-focused. I searched and interviewed at many places and began receiving offers.
BUT – that mortgage tug – kept pulling at me. So, I thought this would be a suitable time for me to get back into Sales or Operations and get to see how the technology affected the users as well as how things had or had not changed. I was able to accept a position as an Underwriter and soon after oversaw a team of underwriters for a region. I got to live and breathe the end of the month cycle again, see how the technology was hampering or helping, provide tips and tricks and I really had a wonderful time.
In mid-2011, Mortgage IT (Information Technology) jobs came calling again. It took me back to Dallas where we selected and rolled out a Loan Origination System, supported Capital Markets and Warehouse software, opened a Call Center, and more. That company was sold to another company, and layoffs were beginning, so I took an opportunity and moved to Houston to do another Loan Origination Selection for another employer, among other projects. Then back to Dallas where a company had bought another company and they needed to consolidate to one system. At that last company, I was Vice President of PMO (Project Management Office). Then leadership changes occurred, and they laid off the entire PMO staff. I secured as many jobs for my people as possible and decided to investigate Consulting. At this point in my career, I had been laid off three times, and climbing that ladder just to get chopped off had become exhausting.
I have known CC Pace since 1998, as they helped us roll out automated underwriting. Following that, I worked with them throughout different employers over the years.
So, we made it happen. In September of 2015, I went to work for CC Pace as a Senior Consultant. It has been so much fun being on this side, we get to help solve so many different problems for so many different clients. From POS (Point of Sale) and LOS (Loan Origination System) Selections to Implementations, Compliance Reviews, Process Reengineering, system tune-ups, staffing reshuffling, website buildouts, security reviews, system assessments, due diligence, and more. Getting to meet so many new people from all over the country and develop relationships has been the most rewarding.
When I moved from temporary to permanent in 1992 as a Loan Processor, my mom wrote me this letter:
On 5-1-71 I began my career in the mortgage industry. Here we are 21 years later, and you are beginning your career in the mortgage industry. My beginning salary was $375 per month and over the years that income has increased 10 times +. I hope you will experience the same kind of financial rewards but more than that I hope you enjoy the work and challenges as much as I have. It’s a good business and you will work with a lot of good people. Good Luck – you deserve it.
She was and is right, my beginning wage was $7 an hour and the financial rewards have been good. But so much more than that, I love the mortgage industry. I have met some of the best people in the world and many of them I am proud to call my friends, 30 years plus, some of them.
Much of what we do in this life is about the journey and nurturing good relationships along the way. On the Consulting side, we get to build so many relationships, see so many problems and help solve those problems. You see problems, we see solutions. What can I help you solve?
The video below is Part 2 of our 3-part series: Building and Securing Serverless Apps using AWS Amplify. In case you missed Part 1 – take a look at it here. Be sure to stay tuned for Part 3!
CC Pace supported So Others Might Eat (SOME) a local nonprofit organization, for our final community outreach event of 2021. SOME is a community-based service organization dedicated to supporting the Washington, D.C. community experiencing homelessness and poverty. SOME provides a variety of services, including affordable housing, counseling, substance use disorder treatment, and job training. Additionally, SOME helps meet the immediate daily needs by providing food, clothing, and healthcare to those in need.
SOME hosts an annual Shoebox Gift Drive each holiday season. This initiative is meant to provide those experiencing homelessness and poverty with immediate living essentials. This December, CC Pacers came together and donated supplies to put together gift boxes. CC Pacers purchased items from hats and scarves to soap and razors, and much more! We were able to pack and wrap nearly 30 shoeboxes in support of SOME’s holiday initiative.
SOME has always had a significant importance to CC Pace, as President, Mike Gordon is a member of their Corporate Advisory Board. We have participated in SOME events for over 2 decades and have witnessed this organization provide so many wonderful services and assistance to those in need.
Interested in how you can get involved with SOME? Visit their website and learn about a variety of ways you can help!
Happy New Year from CC Pace!
AWS Amplify is a set of tools that promises to make full-stack, cloud-native development quicker and easier. We’ve used it to build and deploy different products without getting bogged down by heavy infrastructure configuration. On one hand, Amplify gives you a rapid head start with services like Lambda functions, APIs, CI/CD pipelines, and CloudFormation/IaC templates. On the other hand, you don’t always know what it’s generating and how it’s securing your resources.
If you’re curious about rapid development tools that can get you started on the road to serverless but want to understand what’s being created, check out our series of videos.
We’ll take a front-end web app and incrementally build out authentication, API/function, and storage layers. Along the way, we’ll point out any gotchas or lessons learned from our experience.
Happy holidays from CC Pace! Take a look at our digital holiday card below!
In the push to be able to conduct business during the pandemic, companies sought out new technology to improve their digital capabilities for both internal employee and external customer-facing work. There was a noted rush to select, implement and integrate new technology into the existing infrastructure to keep business moving along. For the most part, the purchase decision was compressed and triggered by the immediate need. As such, there are some decisions in hindsight that may cause regret and others whose terms are not as attractive as expected for a long-term relationship. Also, the selected technology could be a perfect fit, but the implementation may have taken shortcuts in the rush to deliver, and additional work may be desired to further refine the integration or customization to better meet the business needs. Even if no new technology was introduced, regular maintenance tasks were postponed during the pandemic, and training sessions canceled that were needed then but are imperative now.
As we move to the next stage of the pandemic, defining the work arrangements, returning in some way to a physical office location or just settling into a long-term remote work arrangement, it is a good time to take a breath and assess where your applications and infrastructure are today, and take a step back to prioritize key projects and next steps to move forward in whatever the new “normal” may be.
Starting with vendor management and contract review, most organizations do a great job of vetting vendors during the purchase/selection process but fail to follow up on a regular basis to ensure the vendor and its practices maintain the necessary controls to keep their systems supported and your data protected. Given that your vendors had similar stressors maintaining business practices through the pandemic, it is a good time to re-assess their activities to ensure the expected levels of control and security are still in place.
This is also a great time to review your contractual agreements. Identify any agreements that will expire in the near term and start planning for the next steps which could be a replacement or re-negotiation for renewal. Identify any contractual terms that no longer meet your needs, e.g., on-site support with a remote workforce, and layout a new path and desired outcome before approaching your vendors. Ensure any needed or expected vendor certification/licensing is also up-to-date during your review process.
Your infrastructure and its support should be assessed to ensure it is protected, sized, and supporting the organization. Are both hardware and software patches being applied timely? Are there are any components that need to be retired or are no longer supported? Assess whether changes are needed for growth or contraction. Are controls in place to ensure a secure environment for the data and organization? What has changed during COVID-19, and how has that impacted the operation?
There has been a move towards the cloud for a number of years, but the pandemic brought that shift to the forefront for many organizations. Questions to ask include: Is your selected cloud provider providing the service and support you and your organization expect and need? If outsourced, are you getting regular (and useful) reports about the health and security of the environment? Are any identified or contractual service-level agreements (SLAs) being met? Are there SLAs that weren’t defined but should be? Address deficiencies with your internal/external vendors or select new ones, as appropriate.
Software Technology and Documentation
Your software technology is critical to your success. During COVID-19, a lot of projects were put aside for more immediate “keep the lights on” activities. A review of what is listed in your backlog is needed to identify where (and if) issues with key functionality exist. Points of integration should be reviewed to ensure the exchange of data is being completed in a secure manner, seamless to the end-user. In general, complete an assessment to ensure you have the best combination of systems supporting your business operation. This process will ensure awareness of not only immediate needs but those that are just over the horizon. If software was selected in a rush during COVID-19, it’s a good time to look at the industry for alternatives to identify a better fitting solution or to identify enhancements to request of your vendor.
Documentation is an area that was frequently ignored during the pandemic (and other times). There is value to the organization maintaining documentation of your systems and practices. The application architecture diagram is a simpler diagram to create, but is critical to understanding the systems in (and out of) your environment and their interactions. Many organizations have graphical representations of their network, but not of their applications, interactions, and uses. The application architecture and other documentation facilitates communication and understanding within the organization and with your vendors.
The last area that needs attention is one that should be foremost in everyone’s mind and that is security. Security encompasses people, processes, and technology. Attacks can come through any of these areas and vigilance is needed to stay protected. For people, it is important that any training sessions that were postponed during COVID-19 be re-scheduled to educate employees on such things as identifying spam emails and phishing schemes. Processes should be reviewed to ensure that information is being properly protected whether it is paper or digital throughout the process, and only appropriate data is being shared. Finally, the technology needs to be assessed. This can include a review of users and the level of access granted, ensure that anyone that has left the company has had their access revoked, that security levels are commensurate with the roles, etc. Identify any users that haven’t logged in for extended periods and determine if their access is required. Security surrounding applications should be reviewed to ensure that the current protocols are being followed, the complexity of passwords, the number of days between password changes, etc. Administration passwords should also be updated on a regular basis.
While all of the above would normally be considered business as usual, COVID-19 has irreparably changed what normal is. Work that has been postponed, canceled, or set aside should be revisited to identify what is still applicable to maintain a secure and functional operation for the organization and its user community.
Did you know that the first American football game was played in 1869 between Rutgers and Princeton? It would be 51 years later that the NFL was formed in 1920. There’s a whole lot of football history there to be unpacked by aficionados, and here at CC Pace, our employees share that passion for football!
Over the years we have hosted a variety of football-related events including watch parties, festive tailgates, and Superbowl-themed events to get everyone pumped up for the big game! Team jersey days and our yearly football squares for the Super Bowl also help to generate a friendly competitive football spirit throughout the season.
While we love a good football-themed gathering, our competitive Fantasy Football league is truly what sparks the ultimate excitement for CC Pace’s football craze! We are not sure how or exactly when this Fantasy Football league all started, but word around the watercooler is that our President, Mike Gordon, put the wheels in motion while having one of many Monday morning football recaps with people in the kitchen getting their morning cup of joe.
Some of our CC Pace Fantasy Football Leaguers choose to take on their competitors individually while others team up, hoping together they can strategize and outperform their colleagues in the big draft. This is the time of year where you will hear many a conversation amongst CC Pace employees discussing player stats, and how to best keep all that information organized. Do we really expect anything less from a company that has analysts on the payroll? Each week our Football Leaguers closely monitor their standings, re-evaluate their lineups for the weekend and the strategy continues. And, although there is a prize at the end of the season, the most cherished part of the whole endeavor is the bragging rights the winners get to keep for years to come! Our very own CC Pace Fantasy Football Hall of Fame.
So, as we here at CC Pace settle into our yearly football fun, please allow us to leave you with this quote by the famous Coach, Lou Holtz, that stands true both on and off the field, and is something we at CC Pace also relate to: “Ability is what you’re capable of doing. Motivation determines what you do. Attitude determines how well you do it.”
In case you missed it, check out Part 1 of this series here!
By June of 1991, I was in college, and I had been working at Albertsons, climbing the ladder, and was manager of my own department. I had to take mandatory time off because we were trying to catch an inventory thief. I was talking to my Mom, who was a Regional Operations Manager (ROM) for a mortgage company, and told her that I had to take this time off, but I didn’t have any plans. She suggested that I come earn extra money by working in their Shipping Department. So, I did. I became a part-time Shipper and Post Closer. I loved the office life, as it was so different from the grind of the grocery business. It was a grind, don’t get me wrong, but my clothes stayed clean all day and I was learning so much!
(By the way, we did catch the thief!)
There were not any Personal Computers (PCs) on the desks. There were smart typewriters, thermal fax machines, and we used runners (companies that would take a closing package from the mortgage company office to the title office). There were tons of manual forms, file cabinets galore, single – double – triple hole punchers, and colored folders. Heck, you could still smoke in the office back then.
In our department, we used a PC with FoxPro to track everything. The first thing I did was make the database much better. I had been dabbling in computers since I got my first TI Sinclair 1000 in the 8th grade, then graduated to a Commodore 64, then my first Hewlett Packard.
I was hungry to learn as much as I could. I read every manual I could get my hands on. I began reading the loan documents as I stood at the copier making two copies: one to send to corporate and one to retain in the branch. From there, I moved to Loan Setup, and this is where I revolutionized how they put the origination packages together and streamlined that operation. I also was the WordPerfect whisperer and created, updated, and/or streamlined many forms. The Regional Manager didn’t know how to use a computer, so when it was budget time, I was called to work in Lotus 1-2-3 and that was how I learned budgets and P&L statements.
Then in 1992, computers came. These Data Processing folks descended upon our branch. Cables were laid and PCs were put on every desk. I came in over the weekend and followed them around like a puppy dog. Then, after providing some training for everyone, they left. So, who was on-site tech support for all the PCs, the printers, the LAN? You guessed it, me. Printer or PC not acting right? Call Greg! I would intuitively know what to show them or how to fix their issue. I watched as they struggled to enter data and then figured out that I was good at teaching people how to do things and showing them ways to do their jobs faster, more efficiently.
For my actual part-time job, I went on to work in several departments, again, trying to learn as much as I could. My Mom who was the ROM, moved to be the Wholesale Account Executive, and now that nepotism was out of the way, I was offered the full-time job as a Loan Processor. I quit my job at Albertsons and fully devoted myself to mortgage.
Over those first eight years in the industry, I was living the branch life and held positions such as Shipper, Post Closer, Loan Setup Clerk, Loan Officer Assistant, Quality Control Reviewer, Loan Processor, Loan Closer, Pre-Underwriter, Lock Desk Specialist, LAN Administrator, Operations Manager, Assistant Branch Manager, and Loan Officer. I moved all around Texas, from San Antonio to Austin, and then to Dallas.
When I was in Dallas, a unique opportunity came up for me to work in the Data Processing department. I had a direct line to this group and always shared how the system or a form could be better. So, they offered me a job and I moved to Scottsdale, Arizona. I also was able to be on the ground floor of rolling out laptops to our sales force. I got to pick the laptops, load them with the software, work on the interface to the processing system, then fly about the country training and rolling them out. I got to go to conferences and branch events. I did not love living in Arizona, so when an opportunity came up for me to move back to Texas, I took it.
I worked on the Help Desk where my hours were three 12-hour days and a half-day on a Saturday once a month. I loved that schedule. But that schedule was short-lived, as within two months I was a Business Analyst working on the Point-of-Sale software and rolling out laptops for a much larger organization that had also bought another mortgage company. Those were some crazy times and late nights.
I spent the next ten years of my career in Information Technology (IT) roles. I continued to strive for and climb into higher and higher positions with more and more responsibility. I ran Point-of-Sale Systems, Loan Origination Systems, branch and loan officer websites, then three POS systems across three company brands, then consolidation of those three systems down to one. I held the roles of Business Analyst, Team Manager, Project Manager, Program Manager, Business Information Officer, and Assistant Vice President. It was a great time to see all the technology changes within the mortgage industry and be involved in discussions with Fannie, Freddie, HUD/FHA, VA, software vendors, C-Suite level executives, all the managers in between, down to all the individual roles. Curating solutions that came on the heels of adapting to market changes and acquiring feedback from users.
Over almost twenty years, I came to realize that because of my production and operations background coupled with IT knowledge, I filled a great niche because I could speak the Business AND the IT languages and bridge the gaps between the groups.
Then KA-BOOM, www.ml-implode.com became daily life. It was a terrible and scary time for anyone in the Mortgage Industry. By the end of 2008, I, along with 10,000 people at my company, had been laid off.
By this time, I was living in Dallas, TX, and wanted to get back to Austin, TX. So, I sold my house, turned down a lateral-down move to stay with the company that had just laid me off, and headed into the unknown.
Continue following Greg’s journey in part 3 of the series here!
A recent Credit Union Times article noted that while credit unions continue to perform strongly with long-time customers (those over 65 years of age), the industry is struggling to retain and add younger customers. The same article notes that the average age of a credit union customer is 47 years old and that only 10% of people aged 20 – 34 currently utilize credit unions for their financial services needs.
So, why are younger depositors leaving credit unions for other institutions and services? A CU Insight article suggests that a combination of cash incentives, reward programs, and gamified customer experiences are driving younger customers to these providers in large numbers.
This implies a trend that will have devastating impacts to the industry if not addressed.
For the last several years, the industry has managed the problem of growth through mergers and acquisitions (similar to the activity seen in the banking industry in the late ’90s and early 2000s). Asset consolidation has led to a few very large credit unions holding a majority of the industries assets, and according to the American Banker, a group representing 12% of credit unions now hold 81% of all managed assets.
While this has solved the problem of scale for some credit unions, it does not help smaller independent credit unions, nor does it provide a path to long-term, organic growth for larger ones.
So, what’s the solution?
Should credit unions pursue similar strategies to traditional banks to attract customers? This can be tricky, as many credit union customers were attracted because they wanted a very different experience from traditional banking; also, offering considerable up-front financial incentives to attract new customers can be problematic, as the incentives have traditionally been focused on lower overall costs and higher returns on deposits.
How about pursuing more unorthodox methods a la companies like SoFi that provide softer incentives through gamifying customer experience? This might be a reasonable approach to attract very young customers who respond better to these types of incentives. This, combined with robust social media strategies can begin to claw back a portion of the Gen Z and Millennial populations that have begun to abandon their parents’ choice of the financial institution; this might shore up customer numbers, but will not likely have a major impact on assets held.
To be successful in the long term, credit unions must continue to focus on differentiation with traditional banking. Superior customer service has been a cornerstone to the value proposition of credit unions, and the industry must continue to look for ways to promote this fact – along with the generally higher return on deposit and investment products. This can be a challenge given smaller advertising and marketing budgets, but as noted above, properly leveraging lower-cost channels provided by social media can provide significant brand lift with a reasonable investment.
In addition, many credit unions have been expanding their reach into the small business segment within their markets, offering loans, payments processing, and other related services and this class of service could be a significant source of long-term growth if the industry can overcome significant headwinds from both traditional banks and FinTechs (see this article from American Banker). Once again, credit unions bring a unique value proposition compared to these other providers, but it is critical that those advantages are made crystal clear through effective marketing, advertising, and social media campaigns.
In short, credit unions offer some incredibly compelling advantages over traditional banking, as well as stability and reliability compared to FinTechs moving into the consumer and small business banking arena. Recent trends in loss of customers is concerning, but with continued focus on maintaining best-in-class customer service and continuing to offer products aligned with the needs of local markets, along with aggressive attention to marketing and branding through more modern channels will both help stave the loss of customers from newer, younger bankers and demonstrate a focus on continued uncompromising service to its members.
Interest rates are on the rise and affordability is tightening. New and old methods will need to be tapped to continue to put borrowers into homes, are you and your platform ready?
For many, it has been a very long time since anything beyond a straightforward fixed-rate product guideline was added to the LOS platform. In some cases, adjustable-rate (ARM) or other more complicated guidelines have never been entered into the current platforms, as the LOS was replaced with new technology more recently.
It’s time to check your systems to make sure everything is ready for when those new guidelines are needed. Whether it’s an ARM with a SOFR index rate, a piggyback, or some other product, you need a refresher on the data that needs to be collected to define the product. What about documents that may be needed and information the system needs to define new product guidelines. Processes and procedures also need to be reviewed to ensure they address any additional or different steps needed during the origination. Also, the points of integration should be assessed to ensure that the requisite data to support an expanded list of products is fully supported. The last step is particularly important given the addition of technology to support all aspects of digital lending throughout the pandemic.
If you’re ready, CC Pace can help. We have a proven track record of working with our clients to revitalize technology infrastructure, update systems to conform to current practices and implement organizational/process best practices.
Who says Halloween is just for kids? At CC Pace, we have always relished the opportunity to dress up, eat candy and create a spooky ambiance. Through the years, the hallmark CC Pace creativity has run amok when it comes to costumes! The American Flag gang, the Pink Ladies, and President Mike Gordon as Waldo are memorable standouts. We can also proudly boast that our cauldron has bubbled some toil and trouble with all the festive Halloween parties we have had!
In that same ghoulish spirit, and with another Halloween upon us where we will not be able to celebrate together, we decided to memorialize this year’s Happy Hauntings by asking our CC Pace team to send in photos of their Halloween spirit.
So, with a big “Boo!” to you from our crew, we present to you CC Pace Halloween, past and present! Enjoy!
I am a mortgage baby, and proud of it!
That is what I was called, before I even started my journey in the mortgage business, a mortgage baby.
I officially began getting a paycheck in mortgage banking in early 1991, although I knew about mortgages way before I entered the business. I am excited to have been able to evolve and grow into a Director, Mortgage Practice for CC Pace Systems, Inc. I hope to share my knowledge, wisdom, and lesson learned with our many clients.
My mom and dad were both originally in the Savings and Loan business in the early 1970s. In the late 1970s, my dad (Gerry Self) transitioned to being a Mortgage Insurance Sales Representative. My mom (Sylvia Burnett, formerly Sylvia Self) began working for a mortgage banking firm and she had a side gig, underwriting loans for the local HUD (Housing and Urban Development) office, way before Direct Endorsement. What I remember about the early days of that, was that my dad was always on the road and my mom worked a full day, then would bring home boxes of files from HUD and after getting us all nestled into our beds, she would underwrite loans.
Then in 1984, my parents went to work together at the same company. My dad was the Branch Manager, and my mom was the Operations Manager. They opened the Killeen branch, then we moved to San Antonio, and they opened that branch. I would work many hot Texas summer days from 1984-1986 at that company. I did some light clerical work, like answering the phones, filing, typing, organizing, fetching. Lots of fetching.
What I remember from that was that there were no fax machines and certainly no computers. There were typewriters, IBM Selectric III’s, everywhere. The FHA (Federal Housing Administration) forms were multi-page with all sorts of colors with carbon paper in between. There was liquid paper in several colors; Acco punchers and fasteners; file folders and file cabinets; staplers and staple pullers; three-hole punchers; blue pens and red pens. The blue pens were so you could tell it was an original signature. The red pens were used by the underwriters, who, I assumed like teachers, graded your work.
Paper and manual everything was king. Automation was not even a sparkle in anyone’s eyes.
In November of 1986, I turned 16. Over the Thanksgiving holiday, while we were in Lubbock, TX with the grandparents, my parents bought me a 1981 Buick Skylark for $2,000. I got to drive it all the way back to San Antonio, it was awesome. After unpacking from our trip and settling back in, one day after school my mom came to me. She sat me down and very sternly let me know that it was time to find a job. So off I went to the nearest Albertsons, turned in my application, and was interviewed. I was hired that day and I started the very next day. I came home and let my parents know and my mother was flabbergasted, thinking that it would take me more than a few hours to land a job. So, in December of 1986, I started my job as a Courtesy Clerk (Bagger) at Albertsons on the corner of San Pedro and Thousand Oaks and left the mortgage world behind me. Or so I thought…
Follow Greg’s journey in part 2 of the series here!
From the title of this post, it might seem that we are going to beat up on the ‘status reporting’ aspect. Let me clarify here, both are equally important and convey critical pieces of information to the audience.
What I want to highlight in this post is how inefficiencies are caused due to one replacing the other. In organizations using Agile, adapting to the changing landscape is a central tenet to its way of working. How people communicate is a significant factor in the success or failure of an organizations’ ability to adapt to change.
Before we explore how organizations struggle with effectively using the two ways to communicate, let’s first align on what they are.
Status reporting: The primary intent of this interaction is for one stakeholder to provide information to other stakeholders about the current state of progress. It is a one-way conversation with the information primarily flowing from the status update provider to the listener. There might be some interaction for clarification or instruction, but it is not built into the central idea of the interaction.
Inspect and Adapt: The primary purpose of this interaction is for the stakeholders to examine the progress towards the end goal, identify risks, acknowledge impediments and figure out actionable takeaways that will resolve or mitigate any challenges towards progress. Most Agile ceremonies share this primary intent and should be facilitated as such to achieve the aforementioned outcome.
What really happens: No matter how mature an organization is in its Agile journey, organizational factors such as psychological safety and human psychology influence how people contribute to the ceremonies. Let’s take a closer look at a couple of factors:
- FOMO: Fear of Missing Out. When there are no efficient ways to know the latest status of work, people tend to gravitate towards asking for status-related information during Agile ceremonies. If the status is made transparent and highly visible to the stakeholders, it will greatly reduce the desire to discuss it during discussions that should really be inspect and adapt. In Agile organizations, the use of BVIRs (Big Visible Information Radiators) such as Scrum Boards and relevant Agile metrics can accomplish this. It is critical to make the BVIRs readily accessible and easier to consume to get better user adoption.
- Perception and Recognition: Human behavior is often affected by how your actions will make you look. A status report allows a person to state what they have worked on so far and how it will make them look in the eyes of the audience for their progress. Inspect and adapt discussion makes people state the problems they are or could be facing and ask for help. It is a natural human tendency to try and not be the bearer of bad news. Especially in public forums, such as the Agile ceremonies. If people are getting enough recognition for their work and are made to feel safe for opening up and expressing concerns during the inspect and adapt discussions, the Agile ceremonies can become highly effective.
Tactically speaking, standups and scrum of scrums are typical examples of Agile ceremonies that should be heavily focused on inspect and adapt aspects. What ends up happening on most teams and programs is the ceremony turns into a status reporting session, leading most participants to not get true value out of the interaction.
If you would like to get some tactical advice on how to make these ceremonies more effective, please join us in a free webinar on November 3rd at 12pm EST, where I will discuss the topic in more detail with a fun story about chicken curry, draw the parallels and then do a deep dive into some effective techniques you can implement right now to improve the inspect and adapt aspect in your organization. Click here to register.
Metrics are vital to a team. They give us a starting point, just like choosing “my location” on your GPS. Then metrics tell us where we are headed. They help us know whether our team is winning at continuous improvement. They tell us how our journey is going, and where we might be off course.
The stability of metrics demonstrates that teams are predictable and can forecast future work. Many times, it is a combination of metrics that give us the real picture though.
One measure that can demonstrate a team’s stability is velocity. A team made up of dedicated members should have a stable velocity over time, which helps them better determine how much work to commit for a given sprint. So, measuring velocity over a number of sprints is a great Scrum metric. You might think that a rising velocity is good. However, a rising velocity along with rising escaped metrics tells us we haven’t reliably sped up at all. In fact, if escaped defects are rising, we need to fix something else in our process. We may need to slow back down. In contrast, a rising velocity and a decreasing or stable number of escaped defects would be a good team goal.
Another metric for a Scrum team is Committed vs Delivered %. Rather than just focusing on velocity, add a measure of Committed vs Delivered for velocity to see how your team is doing at being predictable. Teams that frequently have a low percentage of Committed to Delivered are committing to too much work in the sprint. If this is happening to your team, it is time to figure out why. Sometimes, we will know exactly what has impacted our metrics, while other times we may need to have a retrospective to discuss why. Escaped defects are important to consider, as a high percent Committed to Delivered is good, lots of rework is not.
While Velocity and Committed vs Delivered % are end-of-sprint metrics, throughout the sprint, a team’s burndown gives us a view into progress during the sprint. It’s important to look at a team’s burndown every day to assess whether the team is likely to complete all the work they committed to. Burn-down gives us the point-in-time view of the work to be completed within the sprint. If the remaining work is far above the ideal burndown line, we may need to have a conversation with the Product Owner about stories that won’t be completed. On the other hand, if the burndown is far below the ideal line, we may be able to bring another story into the sprint.
Some teams go a step further and measure Cycle Time for stories. Cycle Time starts when a team member starts work on the story and continues until the story is moved all the way to the team’s done column. Cycle time can help us determine if we are right-sizing our stories. For Scrum, stories are right-sized to just a couple of days of work or less. If Cycle Time for stories is extending well past a couple of days, you may need to try and break your work down into smaller pieces.
Using a combination of metrics and charts for a Scrum team can help the Scrum team spot problems and see if their experiments are working. These internal team metrics are just the start and give an even fuller picture when customer outcome metrics are added, but that is a topic for another post. Do not let your team meander along. Get them metrics to see where they are and where they are heading.
Our August corporate outreach program invited CC Pace employees, family, friends, and networks to participate in the #StepUpWithCCPace challenge to support the Cystic Fibrosis Foundation. The Cystic Fibrosis Foundation is the world’s leader in funding research, drug development, and searching for a cure for those living with cystic fibrosis (CF).
5 Facts about Cystic Fibrosis:
CF is a progressive, genetic disease that causes persistent lung infections and limits the ability to breathe over time. The type and severity of CF symptoms can differ widely from person to person. Therefore, although treatment plans can contain many of the same elements, they are tailored to each individual’s unique circumstances. The Cystic Fibrosis Foundation does an amazing job supporting these individuals and their families on a wide variety of levels.
The #StepUpWithCCPace 5 Days/500 Miles campaign was presented as a challenge to CC Pacers, family, friends, and their LinkedIn networks. Participants were asked to collectively walk/run 500 miles and/or donate $500 over the course of 5 days. We are proud to announce, that not only did we reach our goal – we far exceeded it! In total, we raised over $1,500 to support the Cystic Fibrosis Foundation.
Visit the Cystic Fibrosis Foundation’s website to learn more about CF and how you can make a difference for those living with this disease. #Givingback
If you missed Philippa Fewell’s Meet Up where she speaks about how Agile 2 came about – you are in luck, we have it here! Philippa shares with us how she and a group of 14 other Agilists reflected together over a period of 8 months to create a new set of values and principles called Agile 2. We invite you to listen, learn and enjoy her lively discussion!
It’s been 18 months since COVID changed our lives, 18 months of living in a surreal world, and 18 months of working from home for most of us. So as a company, how do we keep morale up? How do we keep our employees motivated? Is it possible to still create a fun work environment?
These are questions CC Pace has explored and continues to address on a regular basis. Since March 2020, we have focused on keeping our employees engaged through various online programs, events, and activities. We have discovered that while working remotely can be challenging, it’s important to sustain high levels of collaboration and teamwork. Just because we are remote does not mean that we can’t still have fun together, it just takes some consistency and planning to maintain morale!
To mark this 18th month of Covid, here are 18 ideas to help build up morale and keep your team motivated!
- Virtual Happy Hours – Everyone is always up for a little chit-chat and a cocktail!
- Tools – Providing the right tools needed so your team can get the job done.
- Mentors – Having someone in the organization you can go to for support, questions, or advice helps to preserve a positive attitude.
- Video Meetings – Using apps like Microsoft Teams and Zoom supports that face-to-face connection (smiling more does too 😊).
- Video calls – Different than Video Meetings, one-on-one calls with teammates to maintain and/or create that personal connection and bond.
- Book Clubs, etc. … – Putting together interest groups creates a sense of belonging.
- Wellness Activities – CC Pace recently promoted a walking challenge to motivate employees to team up with a co-worker to get moving and track their miles. #stayhealthy
- Communication – Leadership who genuinely listen and make themselves available are key to achieving open communications.
- Gifts – A company care package or e-gift card lets employees know you are thinking about them.
- Games – Online games can be super fun, we have had success with Whose Fridge is it Anyway?, Guess the Pet?, and Trivia! (Who doesn’t love a little competition!)
- Feedback – Hearing our employee’s thoughts through surveys and discussions gives us the knowledge we need to move forward and create the best environment for our team.
- Kudos – go a long way! We have expanded our Recognition and Rewards program to empower our team with more avenues to acknowledge each other.
- Professional Development – Encouraging your people to keep growing makes them understand they are a valued team member.
- Benefits – Reexamine your benefits to see if there is anything missing so you can offer the best options and comprehensive packages.
- Small Team Lunches at outdoor eateries – While the weather is nice, try to get a small group together for some al fresco dining!
- Setting Goals – Working toward a goal is often a great motivator for employees.
- Knowledge Sharing – One person’s subject matter expertise can go a long way when they share that information with others in the company who can benefit.
- Celebrations – Celebrating various holidays, occasions, work anniversaries, project kick-offs, etc… is a great way to keep employees inspired! There’s always something to celebrate!
Regardless of where your employees are located, we know all aspects of work can’t be fun, but fun itself in the workplace is a great motivator to help get through those tough times!
According to Deutsche Bank CIO Frederic Veron, “enterprises that wish to reap the potentially rich rewards of getting IT and business line leaders to build software together in agile fashion must also embrace the DevOps model.”
Why is that? It’s simple: DevOps is necessary to scale Agile. DevOps practices are what enable an organization to rapidly deploy changes to many different parts of their product, across many products, on a frequent basis—with confidence.
That last part is key. Companies like Amazon, Google, and Netflix developed DevOps methods so that they could deploy frequently at a massive scale without worrying if they will break something. DevOps is, at its core, a risk management strategy. DevOps practices are what enable you to maintain a complex multi-product ecosystem and make sure that everything works. DevOps substitutes traditional risk management approaches with what the Agile 2 authors call real-time risk management.
You might think that all this is just for software product companies. But today, most organizations operate on a technology platform, and if you do, then DevOps applies. DevOps methods apply to any enterprise that creates and maintains products and services that are defined by digital artifacts.
DevOps methods apply to any enterprise that creates and maintains products and services that are defined by digital artifacts.
That includes manufacturers, online commercial services, government agencies that use custom software to provide services to constituents, and pretty much any large commercial, non-profit, and public sector enterprise today.
As JetBlue and Breeze airlines founder David Neeleman said, “we’re a high-tech company that just happens to fly airplanes,” and Capital One Bank’s CIO Rob Alexander said, “We’re a founder-led, 20-year-old technology company.”
Most large businesses today are fundamentally technology companies that direct their efforts toward the markets in which they have expertise, assets, and customer relationships.
DevOps Is Necessary at Scale
Scaling frameworks such as SAFe and DA provide potentially useful patterns for organizing the work of lots of teams. However, DevOps is arguably more important than any framework, because without DevOps methods, scaling is not even possible, and many organizations (Google, Amazon, Netflix…) use DevOps methods at scale without a scaling framework.
If teams cannot deploy their changes without stepping on each other’s work, they will often be waiting or going no faster than the slowest team, and lots of teams will have a very difficult time managing their dependencies—no framework will remedy that if the technical methods for multi-product dependency management and on-demand deployment at scale are not in place. If you are not using DevOps methods, you cannot scale your use of Agile methods.
How Does Agile 2 View DevOps?
DevOps as it is practiced today is technical. When you automate things so that you can make frequent improvements to your production systems without worrying about a mistake, you are using DevOps. But DevOps is not a specific method. It is a philosophy that emerged over time. In practice, it is a broad set of techniques and approaches that reflect that common philosophy.
With the objective of not worrying in mind, you can derive a whole range of techniques to leverage tools that are available today: cloud services, elastic resources, and approaches that include horizontal scaling, monitoring, high-coverage automated tests, and gradual releases.
While DevOps and Agile seem to overlap, especially philosophically, DevOps techniques are highly technical, while the Agile community has not focused on technical methods for a very long time. Thus, DevOps fills a gap, and Agile 2 promotes the idea that Agile and DevOps go best together.
DevOps evangelist Gene Kim has summarized DevOps by his “Three Ways.” One can paraphrase those as follows:
- Systems thinking: always consider the whole rather than just the part.
- Use feedback loops to learn and refine one’s artifacts and processes over time.
- Treat everything as an experiment that you learn from, and adjust accordingly.
The philosophical approaches are very powerful for the DevOps goal of delivering frequent changes with confidence, because (1) a systems view informs you on what might go wrong, (2) feedback loops in the form of tests and automated checks tell you if you hit the mark or are off, and (3) if you view every action as an experiment, then you are ready to adjust so that you then hit the mark. In other words, you have created a self-correcting system.
Agile 2 takes this further by focusing on the entire value creation flow, beginning with strategy and defining the kinds of leadership that are needed. Agile 2 promotes product design and product development as parallel and integrated activities, with feedback from real users and real-world outcomes wherever possible. This approach embeds Gene Kim’s three DevOps “ways” into the Agile 2 model, unifying Agile 2 and DevOps.
Download this White Paper here!
 Agile 2: The Next Iteration of Agile, by Cliff Berg et al, pp 205 ff.
We all are humans and tend to take the easy route when we come across certain scenarios in life. Remembering passwords is one of the most common things in life these days, and we often tend to create a password that can be easily remembered to avoid the trouble of resetting it in case we forget it. In this blog, I am going to discuss a tool called “Have I Been Pwned”(HIBP) which is going to help us find any passwords that were seen in recent cybersecurity or data breaches.
What is HIBP? What is it used for?
“Have I Been Pwned” is an open-source initiative that helps people to check if their login information has been included in any breached data archives circling the dark web. In addition, it also allows users to check how often a given password has been found in the dataset – testing the strength of a password against dictionary-style brute force attacks. Recently, the FBI released a statement that they are going to closely work with the HIBP team to share the breached passwords for users to check against it. This open-source initiative is going to help a lot of customers avoid using breached passwords when creating accounts on the web. We used the HIBP API to help our customers who use custom web-based applications get alerted of any pwned passwords that they used while creating accounts. In this way, the users will be aware of not using such breached passwords that have been seen multiple times on the dark web.
How does it work?
HIBP stores more than half a billion pwned passwords that have previously been exposed in data breaches. The entire data set is both downloadable and searchable online via the Pwned Passwords page. Each password is stored as an SHA-1 hash of a UTF-8 encoded password and the password count with a colon (:) and separated by each line with a CRLF.
If we must use an API to search online for the password that was breached multiple times, we cannot send the actual source password over the web as it will compromise the integrity of the user’s password that got entered during account creation.
To maintain anonymity and protect the value of the source password being searched for, Pwned Passwords implements a k-Anonymity model that allows a password to be searched for by partial hash using search by range. In this way, we just need to pass the first 5 characters of an SHA-1 password hash (not case-sensitive) to the API which will respond with the suffix of every hash beginning with the specified prefix, followed by a count of how many times it appears in the dataset. The API consumer now can search the results that match the source password hash by comparing them with the prefix and the suffix of the hash results. If the source hash was not found in the results, it means that the password was not breached until date.
Pass2Play is one of our custom web-based solutions where we integrated the password breach API to detect any breached passwords during the sign-up process. Below is the workflow:
- The user goes to sign up for the account.
- Enters username and password to sign up.
- After entering the password, the user gets a warning message if the password was ever breached and how many times was it seen.
In the above screen, the user entered the password as “P@ssword” and got a warning message which clearly says that the entered password has been seen 7491 times based on the dataset circling in the dark web. We do not want our users using such passwords for their accounts which could get compromised later using dictionary-style brute-force attacks.
Architecture and Process flow diagram:
API Request and Response example:
SHA-1 hash of P@ssword: 9E7C97801CB4CCE87B6C02F98291A6420E6400AD
API GET: https://api.pwnedpasswords.com/range/9E7C9
Response: Returns 550 lines of hash suffixes that matches the first 5 chars
The highlighted text in the above image is the suffix that matches the first 5 hash chars’ prefix of the source password and has been seen 7491 times.
I would like to conclude this blog by saying that integration of such methods in your applications can help organizations avoid larger security issues since passwords are still the most common way of authenticating users. Alerting the end-users during account creation will make them aware of breached passwords which will also train the end users on using strong passwords.
Everyone says you should use Agile. The call for Agile has reached the CEO level: I myself have heard CEO announcements stating that the organization must use “Agile”—whatever that is, because I wonder how many actually know.
On the other hand, how many Agile proponents actually understand what Agile is? As I wrote in a recent article, Old Versus New Agile, Agile has changed—and changed a lot. Thus if you bring in “Agile” consultants to help, are they using “old Agile,” or “new Agile”?
Old Agile is arguably very limited, and does not acknowledge the realities of a large organization. What I refer to as “new Agile”—and I believe it is described well by Agile 2—is completely focused on the general problem of agility, and how that plays out in the broad range of situations, including and especially large organizations. Because to do big things—profitable things at scale—you need a very sophisticated model. Agile 2 provides that.
I have seen IT managers make tragic and far-reaching mistakes in their attempt to follow “old” Agile. For example, in more than one case an IT SVP eliminated all roles pertaining to testing. I wrote in an article why that is a tragic error that eventually results in terrible quality issues and actually impedes agility.
Old Agile is not all bad. It broke the grip of rigid approaches being pushed at the time by PMI and the procurement school of thought. In a fast-changing market, custom market-facing software cannot be “procured”: it must be seen as something that evolves over time. Agile made us face that. Some of the ideas that it brought into the forefront were:
- Phase-based (requirements, design, implementation) software development does not usually work.
- Business users often do not know what they want or need.
- It is almost impossible to fully design software up front
- Documents alone are not effective for communicating things
- Don’t build something entirely in one go
- Big teams do not work
- Don’t micromanage how developers work
- Don’t trust anything until you see it running
- Build quality in
- More effort ≠ better; automate to avoid effort
- Continuously reflect and improve
These are all good things, especially if one views them as reminders rather than absolutes. But the Agile community also came to espouse some extreme and ultimately toxic viewpoints—again, especially if one views them as absolutes (which is often the case). I consider these views to be part of “old” Agile. These include:
⚠️ Teams do not need leaders, except to “remove impediments”.
⚠️ Always trust the team.
⚠️ A team must be completely autonomous.
⚠️ Multiple teams will collectively self-organize.
⚠️ Written communication is not important.
⚠️ Everyone must sit together.
⚠️ Most challenges pertain to individual contributor team behavior.
⚠️ Teams can resolve technical issues if leaders merely “get out of the way.”
⚠️ If Agile does not work at scale, it is the organization’s “fault.”
⚠️ Specific technical practices such as pair programming and TDD are always “best.”
In contrast, “new” Agile ideas are markedly different. A tiny sampling of these authors includes Klaus Leopold, Nicole Forsgren, Jeff Dalton, David Marquet, Matthew Skelton, Manuel Pais, Mirco Hering, Mark Schwartz, and Gary Gruver, as well as some “old Agile” authors who have evolved a mature view over time (or had one from the beginning) such as Johanna Rothmann, Diana Larsen, as well as myself and the 15 members of the Agile 2 team.
You probably see now that the peril of bringing in Agile consultants is that you might not know if they embrace “old” Agile ideas or “new” Agile ideas. But that is not all. “New” Agile includes many additional narratives that are critical for achieving agility at scale. The Agile 2 team attempted to summarize these through its principles, but a very abbreviated summary is as follows. Note that these are considerably at variance with “old” Agile, but are well aligned with the “new” Agile that Agile 2 and many of the above authors advocate:
- The predominant forms of leadership are the most determinant factors of success.
- Someone usually needs to coordinate things, and be the organizer.
- On any team, one wants a “missionary, not mercenary”—someone who values the organization’s success first and foremost.
- There are many forms of leadership: team focused, advocate focused, technically focused, and maybe others; as well as individual leadership.
- The organization needs to explicitly focus on encouraging benign and effective forms of leadership, and take steps to avoid giving the wrong people authority—avoiding people who “seem like leaders,” and instead selecting (actively or passively) those who are the “missionaries” and the helpers.
- Leadership is needed at every level of an organization, and the same principles apply.
- Leaders of tech-focused organizations not only need to understand outcomes, but they also need to understand how the work is done, because the “how” is often strategic.
On a systems approach:
- Don’t be extreme, unless the situation is extreme.
- Always think holistically—in terms of the whole system.
- Product design is an essential element, apart from product implementation; yet the two are intertwined.
- Direct feedback from customers and stakeholders is the only way to measure success.
- Product implementation teams must be partners with business stakeholders—not mere order takers.
- Data is strategic, and it must not be treated as an afterthought.
- Collaboration is essential, but so is deep thought. People often need quiet and isolation in order to think deeply.
- People work, communicate, and collaborate best differently. A one-size-fits-all approach is not effective.
- Team autonomy is an essential aspiration; but for a complex endeavor, full autonomy is seldom fully realizable.
- Some people want to be experts. Some people want to be generalists. Some are in between. All are valuable.
- Both teams and individuals matter. Don’t over-emphasize one over the other.
- A team should collectively decide how to approach its work; but then individuals perform the work and interact as they need to.
- Transformations are mostly a learning journey—not a process change.
- Never use a framework as defined: treat it as a source of ideas—not an Agile-by-numbers process.
Agile is not a single theory or approach. There is great diversity of thought within the Agile community. When choosing consultants or an approach for adopting Agile methods, be thoughtful about who you choose. Ask yourself, are they interested in putting people on the ground to deliver a commodity service? Or are they deeply thoughtful about what they do, and represent mature and effective viewpoints? And will the people they provide be as up-to-date and astute about the nuances of old versus new Agile ideas as those who have had conversations with you? Because it matters.
Recently, I read an article titled, “Why Distributed Software Development Teams Work Infinitely Better”, by Boris Kontsevoi.
It’s a bit hyperbolic to say that distributed teams work infinitely better, but it’s something that any software development team should consider now that we’ve all been distributed for at least a year.
I’ve worked on Agile teams for 10-15 years and thought that they implicitly required co-located teams. I also experienced the benefits of working side-by-side with (or at least close to) other team members as we hashed out problems on whiteboards and had adhoc architecture arguments.
But as Mr. Kontsevoi points out, Agile encourages face-to-face conversation, but not necessarily in the same physical space. The Principles behind the Agile Manifesto were written over 20 years ago, but they’re still very much relevant because they don’t prescribe exactly “how” to follow the principles. We can still have face-to-face conversations, but now they’re over video calls.
This brings me to a key point of the article -” dispersed teams outperform co-located teams and collaboration is key”. The Manifesto states that building projects around motivated individuals is a key Agile principle.
Translation: collaboration and motivated individuals are essential for a distributed team to be successful.
- You cannot be passive on a team that requires everyone to surface questions and concerns early so that you can plan appropriately.
- You cannot fade into the background on a distributed team, hoping that minimal effort is good enough.
- If you’re leading a distributed team, you must encourage active participation by having regular, collaborative team meetings. If there are team members that find it difficult to speak above the “din” of group meetings, seek them out for 1:1 meetings (also encouraged by Mr. Kontsevoi).
Luckily, today’s tools are vastly improved for distributed teams. They allow people to post questions on channels where relevant team members can respond, sparking adhoc problem-solving sessions that can eventually lead to a video call.
Motivated individuals will always find a way to make a project succeed, whether they’re distributed, co-located, or somewhere in between. The days of tossing software development teams into a physical room to “work it out” are likely over. The new distributed paradigm is exciting and, yes, better – but the old principles still apply.
Organizations with internal cultures that are aligned with their strategies are far more effective than those without aligned cultures. Decades of data prove this. For example, over the last 50 years, culture specialist Human Synergistics has compiled data on more than 30,000 organizations and it clearly shows strong correlations between specific organizational culture attributes and business performance. Yet it is common for organizations to ignore culture when trying to implement their strategies.
Agile 2 is a more mature version of Agile, and it relies on having a supporting healthy culture. In fact, analysis that Agile 2 Academy has done with Human Synergistics shows that Agile 2 ideas strongly align with what Human Synergistics calls a Constructive culture, which is the most effective kind.
When an organization decides to adopt Agile 2 (or any Agile) methods, it is common to define a set of “practices” that development teams must follow. This is an essential step, but there are some great perils in assuming this approach is enough:
- Many, if not most, practices require people to learn new skills, make new judgments, and behave in new ways. Practices alone are not enough.
- Most of the obstacles to using Agile 2 (or legacy Agile) methods actually exist outside of the development teams. These obstacles are widespread and manifest as management behaviors, lack of supporting systems that Agile teams need, and processes and procedures that make it nearly impossible for teams to operate with agility.
Peril #1 means that people will not be able to execute the practices. They will “go through the motions”—but Agile 2 (agility) is, in its essence, a replacement of step-by-step processes with just-in-time contextual decision-making. If people follow practices and make poor judgments, then the organization will suffer from ongoing bad decisions and poor outcomes. But if the organization’s culture is one that encourages people to seek safety through following procedure, rather than relying on their judgment, then they will not be willing to make judgments: they will copy what others do, and perhaps do the wrong thing.
Peril #2, that most obstacles to agility originate from beyond the teams, is seldom appreciated by organizations beginning an Agile journey. Senior leadership often views Agile as something that development teams and individual contributors do. They don’t realize the extent to which Agile—having agility—relies on having the right support systems in place and the right kinds of leadership supporting the teams.
If the organization has a culture of hands-off leadership, then people who find themselves in a leadership role will not know how to behave when leadership is needed. For example, a common situation is when managers have learned the Agile practice that teams “self organize” but do not realize that that is just a placeholder or reminder. Most teams cannot self-organize well; they need leadership. Self-organization is an aspiration, not a starting point.
The need for leadership is even more acute when one has many teams, and they need to coordinate, and resolve issues such as “How will we design the product? How will we involve real users? How are we going to integrate? How will we manage quality? How will we support our product? How will we agree on branch and merge strategies for the product as a whole?”
When people in a non-Agile organization implement Agile practices, they look for a rule book or procedure to follow, because that is what they are used to, but there isn’t one. If you were to create one, it would not work everywhere, because every Agile decision and judgment is contextual. It always depends; that is what yields agility and makes it possible for people to select the shortest path for each situation.
The above are aspects of the organization’s culture: the ability to discuss issues openly and honestly so that they can be resolved, the willingness to take risks when making a decision, and the patterns of leadership that people have learned. There are many other dimensions of culture that are essential for agility, such as the inclination to learn, the tendency to try things on a small scale before scaling up, and the acceptance of things not going perfectly the first time.
As Peter Drucker said, “Culture eats strategy for breakfast,” and that certainly is true for Agile transformations. If you don’t address your organization’s culture, your agile strategy with its new practices will fail to yield the desired outcomes, and Agile will become a source of problems instead of a driving force for business agility. The good news is that culture can be changed, with the right commitment and the right approach. Agile 2 Academy considers culture improvement to be an important element in business agility. An Agile transformation strategy that includes analyzing and improving your organization’s culture is far more likely to succeed than simply adopting a set of agile practices or frameworks and hoping for the best.
 The best-selling book Accelerate documents research that makes this connection in the context of Agile and DevOps.
Did you know nearly 50% of the world‘s population uses social media platforms? Social media is far-reaching, powerful and has become a necessary component of everyday life. It has certainly changed many aspects of our day-to-day needs, from the way we keep up with the news to the way we interact with our peers.
At CC Pace, we strive to use social media to tell our story, share industry knowledge, and connect directly with our clients, prospects, candidates, and team members. You can find us on LinkedIn, Facebook, Twitter, and YouTube. Our goal with all of these platforms is to provide a way for our followers to relate to us on a more personal level. A goal that has become particularly important to us as we have been forced to relinquish our much-appreciated personal connections, and transition to this mostly digitally connected world we are living in.
While we work hard to keep you informed of all our news, offerings, job opportunities, and thought leadership we also like to focus on the human aspects of CC Pace. We recognize how important it is to be able to put a name with a face, and to share a story at a personal level, which is why we revamped our YouTube channel! Now, when you visit our YouTube channel not only are you able to watch a webinar, and learn more about what we do, but you can also hear directly from many of our team members, join in the fun and see the lighter side of CC Pace. We invite you to take a moment and explore what our YouTube channel has to offer and, if you like what you see, become a follower and subscribe!
Click here to download this white paper.
To learn more about Agile 2, visit the website here.
Last month CC Pacers participated in a community outreach event to support Animal Friends – VA. Animal Friends – VA is a small local non-profit based out of Woodbridge, VA. They are a no-kill foster-based rescue organization dedicated to saving and finding homes for companion animals in our communities. Having been founded in 2015, Animal Friends – VA is an organization of volunteers who are dedicated to saving the lives of surrendered, abused, and neglected animals. The organization relies solely on generous donors and adoption fees to finance their operation. Although the COVID-19 pandemic has halted in-person adoption events, Animal Friends – VA has continued their mission to service neglected animals in the Northern Virginia area.
In support of this organization’s wonderful cause, CC Pacers collected a variety of items and donations. In total, CC Pacers donated dog beds, toys, crates, treats, and hundreds of pounds of dog food – amongst other items. In addition, CC Pacers also made direct donations to the Animal Friends – VA organization. In lieu of participating in in-person outreach events, CC Pace will continue to find new and creative ways to support our community. A big “Thank You!” to all of the CC Pacers who participated in this event!
Looking to get involved? Great news – there are many ways you can support Animal Friends – VA! Options to help include applying to adopt or foster, donating through their Amazon Wish List, or making a direct monetary donation. In addition, once in-person donation events resume Animal Friends – VA will be looking for volunteers for transports and to lend a hand at adoption events. To learn more about Animal Friends – VA, check out their website.
I sincerely hope that you’ve been enjoying Mike Gordon’s recent posts on the changing landscape of banking in the digital world. (If you missed them, please bookmark this post and click this link to read them before continuing any further.) Mike has done a great job of outlining many of the macro-level changes afoot among the banking industry leaders, the innovators and the smaller local lenders as they respond to customer demands and competitive pressures in a time of rapid acceleration of mobile computing and personalization of services available in finance. Mike deftly explores how the responses may vary by institutional types along with his insights as to why the digital approach most often aligns with the customer population that typically defines their respective markets.
I recently ran across an excellent thought piece from Alex Johnson and Darryl Knopp of FICO, based on a session they presented (virtually, of course) at an American Banker’s Digital Banking 2020 conference in December and was struck by how well it complemented Mike’s posts at a more tactical and granular level. The executive summary of their session, entitled “The 11 Commandments of Digital Banking”, can be accessed here (Download Executive Summary). I think that you will agree that Alex and Darryl’s “commandments” are well reasoned and thought provoking in the way that they articulate the customer experience requisites of our times, well punctuated with humor and the obligatory TikTok reference our pop culture demands. Coupled with Mike Gordon’s overviews of the current landscape, these pieces give us a lot to think about how well we are doing with regard to transforming our own businesses to better serve our customers and keep up with the times.
Please drop in a comment to let us know how your own digital transformation is going. We would love to hear from you.
Last year, we worked with experts from George Mason University to build a COVID screening and tracing platform called Pass2Play. We used this opportunity to implement a Serverless architecture using the AWS cloud.
This video discusses our experience, including our solution goals, high-level design, lessons learned and product outcomes.
It’s specific to our situation, but we’d love to hear about other experiences with the Serverless tools and services offered by AWS, Azure and Google. There are a lot of opinions on Serverless, but there’s no doubt that it’s pushing product developers to rethink their delivery and maintenance processes.
Feel free to leave a comment if we’re missing anything or to share your own experience.
We would like to introduce Deepak Palanivelu to you. Due to Deepak’s positive experience with CC Pace as a contractor, he approached us regarding his desire for a permanent position. We jumped at the chance to bring him on as a full-time team member. Here Deepak shares his story of the whole transitioning and on-boarding process that took place for him to become a CC Pace employee.
Welcome to the CC Pace family Deepak!
It is pretty safe to say that, as we enter our 12th month of quarantining and the pandemic lifestyle, we are all experiencing COVID fatigue. So, rather than evoke a collective groan with yet another “here’s how to navigate the quarantine lifestyle” post, we have decided to try and lighten up the COVID experience a little with an entertaining review of how things have changed. So, without further ado, here is CC Pace’s What’s In and What’s Out list! Take a look and please let us know if there is anything we missed on our list – enjoy!
|Conference calls||Teams meeting with fun together modes|
|Short emails with one question||Slack or DMs|
|Team lunches||Door Dashed lunch|
|Phone calls||Video Calls|
|Lengthy in-person meetings||Emails with bullet points and lists|
|Book Clubs||Netflix recommendation discussions|
|Company outings||Online Trivia games|
|Commuting to work||Signing into Teams app or Zoom|
|Printer jamming||Internet connection issues|
|Office inside jokes||Company memes|
|Alcohol shots||Vaccine shots|
|Starbucks||Expanding your Keurig coffee selection|
|“You’re on Mute”||Awesome virtual backgrounds and cameo family member sightings during virtual meetings|
|Juggling kids activities to keep them entertained||Juggling kids online class schedules|
|Happy Hour at the local bar||Personal booze stockpiles|
|Business attire||Sweats, yoga pants and pjs|
|Workplace status quo||Angling your camera just right to ensure your PJ pants are not visible during your Teams meeting|
|Dry Cleaners||Never ending laundry piles|
|Lunch hour errands||Walking your dog 4 times a day|
|Hanging out at the water cooler||Never ending group chats|
|Picking up something for dinner||Cooking at home and getting your Micheline star rated Chef groove on|
|Airpods||Noise Canceling Headphones|
|High Heels and dress shoes||What are shoes?|
|Talking over a cube wall||Stalking co-worker’s availability status on Teams|
|Office floorplan||Makeshift home offices on kitchen counters|
|Grabbing something from the vending machine||Rummaging the fridge and/or pantry|
Small and medium sized companies are trying to return to “normal.” This short blog by guest blogger, Dr. Amira Roess, provides some guidelines. Dr. Amira Roess is a Professor of Global Health and Epidemiology at George Mason University.
It’s not going to be easy, and we may not get back to a pre-COVID workplace for another few years, but it can be done.
A critical factor is employee peace-of-mind. There are three actions an employer can take to ensure employee peace-of-mind:
- Take steps to prevent employees that may be infected from coming to work (i.e. Daily Symptom and Exposure Screening)
- Take steps to remove opportunities to become infected in the workplace (i.e. workplace hygiene and air flow)
- Take steps to rapidly remove employees from workplace that have been exposed (i.e. Accurate and Rapid Contact Tracing)
Daily Symptom & Exposure Screening apps provide a simple way for employees to check their symptoms. The questions on the screening app should be curated by an epidemiologist based on the latest scientific finding from the Center for Disease Control (CDC) as well as other credible sources.
An app that automatically sends daily reminders and/or alerts to employees to complete the screening can reduce the workload in managing the process.
Workplace hygiene must be maintained. Employees must avoid using other employees’ phones, desks, offices or other work tools and equipment, when possible. If you cannot avoid using someone else’s workstation, clean and disinfect before and after use.
Clean and disinfect frequently touched objects and surfaces, like workstations, keyboards, telephones, handrails and doorknobs. Dirty surfaces can be cleaned with soap and water before disinfection. Choose the right disinfectant for your surface from EPA’s List N: Disinfectants for Coronavirus (COVID-19).
Wear a mask in all shared spaces, especially where staying 6 feet apart (about two arm lengths) is not possible. Interacting without wearing a mask increases your risk of getting infected. Note: wearing a mask does not replace the need to practice social distancing.
Employees should wash hands often with soap and water for at least 20 seconds or use hand sanitizer with at least 60% alcohol if soap and water are not available. If your hands are visibly dirty, use soap and water over hand sanitizer.
All medical professionals know to avoid touching your eyes, nose and mouth if you haven’t washed your hands.
Employees must remember to cover mouth and nose with a tissue when coughing or sneezing, or use the inside of your elbow. Throw used tissues into no-touch trash cans and immediately wash hands with soap and water for at least 20 seconds.
Indoor spaces should be evaluated to ensure that maximum airflow is supported. High quality portable HEPA filters can provide an additional layer of protection.
Contact Tracing is very important. Should any employee find out that they are positive for COVID, anybody that was exposed (i.e. more than 15 minutes in less than 6 feet proximity) should be notified and instructed to quarantine immediately.
Here is a link to the CDC website with Quarantine instructions. https://www.cdc.gov/coronavirus/2019-ncov/if-you-are-sick/quarantine.html.
It is strongly recommended to use an automated Contract Tracing system to get accurate time and distance between employees. These systems can also identify where workplace operations result in unintended congregation.
CC Pace has teamed up with George Mason Professors, Dr. Roess and Dr. Lance Shirley, to create Pass2Play.
Pass2Play is a combined Daily Symptom & Exposure Screening and Contract Tracing App that is designed to Provide for Employee Peace-Of-Mind, Ensure Employee Health & Safety, and Maximize Workspace Uptime.
For a demo and purchase: firstname.lastname@example.org
A look at Agile 2’s values and why we need both sides of the coin to create value.
While the values of the original Agile Manifesto have helped shift the way software is developed today, it is very much left to the interpretation of the individual applying them as to how it should be done. This interpretation can often be dogmatic to focus solely on the left, sometimes at the total exclusion of those on the right, even though it clearly states “That is, while there is value in the items on the right, we value the items on the left more”.
Agile 2 consists of six values and 43 principles. It comprises a deep and nuanced set of ideas, and all of its ideas are supported by the thoughts that led to them. In this article I am going to provide a view into Agile 2’s six values and why we chose the word ‘and’ instead of ‘over’. Agile 2 seeks a balance of both the left and the right, both are needed, and both are useful. Also, Agile 2 seeks to speak to a broader range of activities beyond only software, including product development in general, and in fact any collaborative human endeavor.
The Values of Agile 2
Let’s take a look at them one by one.
1. Thoughtfulness and Prescription.
Frameworks are good and useful. They often give us a place to start and help us to solidify an approach. But they should not be followed blindly without considering your own context – where are you and what can and can’t you do in the context of your organization. Many variables are at play to construct the perfect environment for a framework to succeed, including organizational structure, culture, compliance regulation, and leadership support to name a few. A practice that is best for one organization may not be the best or have a chance of succeeding in another. That is not to say that you can’t move towards an ideal, but it very often isn’t the place you can start.
This contextual variability is why thoughtfulness is essential when applying a framework, or any practice or methodology. However, there are cases when one should start with a well-defined practice and follow it precisely. For example, if one is replacing a component of a complex machine, such as a blade on a jet engine, following procedure is often essential for ensuring that it is done right. Lives and safety might depend on following the procedure rather than improvising.
Still, judgment is sometimes required. Surgeons often have procedures for specific types of operations, but they need to be able to improvise, using their own judgment, when things do not proceed as expected; their experience and judgment are key, and the patient’s life might depend on it.
There is a place for prescription; and there is a place for thoughtfulness. Knowing the right balance is a matter of context.
2. Outcomes and Outputs
In the course of product development, outputs are the things that get produced by the development teams. These are usually design artifacts: digital files that define the product and its fabrication (hardware) or deployment (software).
Outputs are important – they help us measure our progress using metrics such as the team’s throughput, number of defects, quality of the software etc. These are mainly what you might call activity-based measures. But ultimately, we are building products or creating a service for our customers using Agile to achieve some business outcome. Sure, the customer will care about the quality, no one wants a product that is not stable, and the organization may not achieve its revenue target or market share if the product is not released on time. But the product also needs to be what the customer wants and will use. It must be the right product and someone or some group needs to be accountable for directing that vision to achieve the desired outcome, which is the true measure of success for the organization.
So, outputs matter: they are essential elements of any process; but they are not the end goal. The end goal is the outcome.
3. Individuals and Teams
We often hear there is no ‘I’ in ‘Team’ and much of what is written about Agile is written regarding the practices of the team. Teams are necessary to accomplish much of what we do, as no one person has the knowledge or capacity. But Agile often advocates for the team’s preference over the preference of the individual, be it with team norms, communication style, and even the team environment. This can be to the detriment of the individual, which can then cascade into the detriment of the team reaching its goals.
Balance is needed so as not to stifle creativity or alienate team members simply because they do not think, learn, or process information in the same way. It is necessary for teams to have norms but sometimes allowing someone to operate outside of the majority’s norm is needed too to accomplish the team’s goal.
4. Business Understanding and Technical Understanding
We often hear that business is the driver, and that technology is the enabler, that the business is responsible for the “what” and that IT is responsible for the “how”. This thinking has led to many structures where development teams are led by product managers who have a great understanding of their domain but very little understanding of how it will be implemented and vice versa. But knowledge of both is necessary to make optimal decisions.
Technical decisions have financial and future business impact, and business decisions have financial and future architectural impact. Not every person can have a deep understanding of both, but they should not entirely shift the accountability of understanding to someone else. Instead, they should seek to understand as much as possible and collaborate closely.
5. Individual Empowerment and Good Leadership
Self-organizing teams is one of the first things people often talk about when discussing Agile. Two of the principles behind the original Agile Manifesto state:
“Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done” and
“The best architectures, requirements, and designs emerge from self-organizing teams.”
These are often translated into “leave the teams alone and don’t tell them what to do”. Yet not all teams are ready for that level of autonomy and authority.
Empowering teams, or individuals for that matter, is a great motivator. It can bring about better outcomes, and it can help to build future leaders within the organization. But to empower people without some level of supportive leadership and assessment is to set them adrift. Borrowing from a talk by former Captain David Marquet, teams need to have clarity of purpose to set direction and competency and the capability and skills necessary to get the job done . Good leadership will assess the level of oversight and direction that the team needs and help them navigate while teaching them how to make good decisions on their own.
6. Adaptability and Planning
One of the original values of the Agile Manifesto contains the phrase “…responding to change over following a plan”. I do not think anyone would disagree that planning can be useful, or that if there were a significant change that would cause the goal to not be achieved then adapting the plan would not be a good idea. The point is that both the act of planning and the ability to adapt that plan are valuable.
The planning in and of itself helps us to think through the variables that would have us choose one option, course of action, timeline, etc. over another. It helps us think through the constraints we must work under and the risks we face if we come up against them. Keeping these things in mind with respect to what is occurring while executing the plan gives us useful information, we can use to adapt the plan for a better outcome.
Both sides of the coin, heads and tails, are necessary to create value. Agile 2 believes that both sets of values are necessary to achieve agility. Balance is needed and consideration for the context of your situation when applying practices that might favor one over the other. I do not believe the Agile Manifesto meant to infer only one side of the coin either, and that the word ‘over’ has led to misinterpretation and rigidity on how to apply it. I could be wrong in my view and understanding also. Therefore Agile 2 has provided interpretation and insight as to how the values were derived, so as not to be misinterpreted. There is a lot of thought and experience behind them from the original authors. However, we expect Agile 2 to evolve and develop with input from the community. We hope that you take some time to review Agile 2 and add to the ideas and content that comprise it.
CC Pace was recently featured in Agile Uprising’s Blog series. Agile Uprising is a network that is focused on the advancement of the Agile mindset and professional networking between leading Agilists. In the blog, CC Pace created a short video where we highlighted one of our latest projects! Bobby Pantall, CC Pace Lead Technology Consultant, speaks to our experience building an app for a startup company named Twisty Systems. This app that was developed is a navigation app aimed towards driving enthusiasts. In the video we describe the framework of the Lean Startup methodology and some of the highs and lows in the context of the pandemic and releasing a new app.
Enjoy and please share your thoughts on this project!
It’s an understatement to say that 2020 has been a challenging year. In the midst of a pandemic, CC Pace has been celebrating a milestone anniversary of 40 years in business! To celebrate, we decided to host a 40th Anniversary Community Outreach Challenge. The pandemic has certainly highlighted the need for community service and outreach, we in turn challenged our employees to go out and make a difference in their communities!
Despite the challenges COVID-19 presented, CC Pacers continued to show overwhelming support in a variety of ways by donating masks to those in need and supporting organizations close at heart. In addition, CC Pace held a company-wide food drive to support of the Lorton Community Action Center, where together our team donated close to three hundred pounds of food!
In total, CC Pacers donated directly to 10 different organizations, including – two universities, two animal shelters, and multiple local and national non-profits all over the country. And, while some took a more traditional approach, others found creative ways to make a difference. For example:
- Donating 40 handmade masks made by an employee and their spouse.
- Committing to perform 40 acts of kindness throughout the year.
- An avid coin collector on our team, decided to sell one of his coins from 1940 and donate the proceeds directly to charity.
- Conducting and donating 40 hours of Agile Trainings as a fundraiser to the Los Angeles Telugu Association. The proceeds from those trainings, which totaled about $22,000, were given to promote community activities, art and culture.
Wow! Well done everyone! A big “Thank You” to all of our CC Pacers for giving back in so many creative ways! Happy 40th Anniversary CC Pace – here’s to 40 more!
If you would like to learn more about any of the organizations CC Pacers have supported this year, please visit the links provided:
- Houston Diaper Bank https://houstondiaperbank.org/donate/
- WolfTrap Animal Rescue https://www.wtarescue.com/support-us
- Fairfax County Animal Shelter https://www.fairfaxcounty.gov/animalshelter/getinvolved
- Shelter House https://shelterhouse.org/get-involved/
- Give Essential https://www.giveessential.org/help
- Capital Area Food Bank (feeding America) https://www.capitalareafoodbank.org/how-to-help/
Welcome to our last blog in our 40 Years and Forward series, where we introduce you to 40 Fun Facts about CC Pace! In this blog series we have taken a stroll down memory lane looking at how CC Pace started and has evolved, as well as what makes our corporate culture unique. Now we ask you to discover 40 Fun Facts about us from the last 4 decades as we share some fond memories, interesting tidbits, and laughs!
We would like to say to all our clients, friends and colleagues who have worked with and supported CC Pace over the years a heartfelt Thank You! We are very excited to what the future holds as we move forward on our journey!
As 2020 has unfolded, our development team has been working on a brand new app: Pass2Play! Check out the video below to see all of its features and capabilities!
To learn more about Pass2Play click here!
It is almost a certainty in years to come, that we will all recall that period in March 2020 when everything started closing down due to COVID-19. The weeks leading up to this time we kept hearing more about this mysterious virus and the awful effects of it. As a result, many of us started preparing for the possibility that we ourselves would be quarantined for a couple of weeks. Fast forward to November 2020 and here we are, still in quarantine as states continue to figure out the best and safest ways to reopen.
Prior to the COVID lockdown, we here at CC Pace would have never imagined that we could transition our entire workforce to go 100% remote overnight, and much less do it seamlessly – but that is exactly what we did! Our entire staff has effectively been working remotely for 8 months, thanks in big part to our technology group who had already transitioned the bulk of our storage to the cloud, and had implemented Microsoft Teams for more successful and personal communications among our employees.
When the CC Pace team transitioned to full work-from-home status overnight we didn’t let quarantine affect our productivity nor the quality of our work. We hit the ground running and have not stopped. If you were to ask us how we did it, we would have to say that the key has been communication. Our team has adjusted and embraced new modes of communication: Meetings – join us in Teams, chats – ping me whenever, kudos – keep them coming, file sharing – here’s the link, screen sharing – take a look at this, all of this along with video calls have helped us to stay in touch and most importantly stay connected! (Of course, a few virtual happy hours and events have helped too!)
It’s this level of adaptability and agility that has brought us our success. Seeing our team be able to continue to produce and develop superior results only confirms what CC Pace has always stood by, our people are our most important asset! #staysafe
In the first installment of our Product Owner Empowerment series, we talked about the three crucial dimensions of knowledge that a Product Owner’s effectiveness is measured on. We looked at how various aspects of empathy influence a Product Owner’s ability to connect with the team, client and organization in our second post. In our third and final post in this series, we are going to look at the impact that psychological safety has on a Product Owner’s success.
Psychological Safety: Psychological safety is a state of mind and a cultural aspect that is created and fostered by someone or something other than the subject themselves. When people in the organization are afraid to make difficult choices and shy away from having tough conversations, it is generally due to a lack of psychological safety. Various factors contribute to how safe people feel psychologically in an organization. Empathy, as discussed above, at all levels plays a big role in this. If the culture, in general, is more empathetic, there will be a higher level of psychological safety. However, it is not the only factor. Let’s dig a little deeper on this factor and see how PO’s success is tied to psychological safety for themselves and the teams they are working with.
- Psychological Safety for Teams: In the case of teams, it is usually the leaders that are responsible for ensuring that team members feel psychologically safe to work in challenging situations with often unpredictable outcomes. Agile requires teams to be flexible and collaborative in their approach to address the ‘just-in-time’ nature of work. Innovation, exploration, and taking risks is a necessity to succeed in such an environment. This comes with the possibility of teams running into occasional failures that should be treated as learning opportunities. But, if the organizational culture is not forgiving of failures, it leads to teams not feeling safe enough to take the risks and challenges they may need to, to optimize value delivery. Leaders should actively address the topic of psychological safety and ensure that they foster a culture that encourages innovation and taking calculated risks.
- Psychological Safety for the Product Owner: The Product Owner is in a unique position having a tremendous influence on a team’s psychological safety, but in turn, are equally or proportionally affected by the psychological safety afforded to them by their leadership. A Product Owner who is well engaged with the team will need to make decisions regarding priority, scope, and timelines. An empowered Product Owner will be able to make such decisions with appropriate communication, keeping the team working at a sustainable pace. However, we often see organizations where such pivots must go through multiple levels of approvals, often surrounded by process constraints and red tape. This causes the organization to see change as undesirable and anyone bringing the change is viewed as the bearer of bad news.
Having leadership that welcomes change, is key to providing psychological safety to the Product Owner and the team. It is not sufficient for leadership to merely say that they support and welcome change. They need to look at systemic and cultural aspects of the organization that might be working against this mindset and actively work to realign them to an Agile way of working. It may not be the norm in some organizations to have leadership unsupportive of change, but a delay in the ability to pivot can lead to periods of unsustainable workload on the team while the Product Owner is negotiating upwards. To truly support psychological safety, allowing for making difficult choices and having tough conversations, organizations need to embrace decentralization decision making and empower the Product Owner and teams as much as possible.
I hope you enjoyed this series. Throughout these three posts, we explored various factors that impact the ability of a Product Owner to work effectively in their role and serve the purpose they are meant to. They must be empowered with knowledge of not just the business domain, but also the delivery and process knowledge to successfully operate in the organizational context. Empathy at different levels of the organization and towards the customer, whether they are internal or external, is crucial to move the product in the right direction. Psychological safety is often an unmeasurable and underlying factor that should be proactively managed by leadership and ingrained in the culture and processes of the organization to truly empower their Product Owners.
As a final thought, if you’ve enjoyed this series or have additional questions on how to truly empower your Product Owners, join me for a FREE webinar on Product Owner Empowerment. We have a few seats available (on a first-come basis) and invite you to register today.
In my previous blog, I highlighted that different banking “personas” have differing goals with respect to digital banking. The large, national financial institutions envision digital banking as being a fundamental competitive differentiator they need to continuously build upon. The smaller community banks and credit unions are looking to continue to provide an attractive, local alternative like they have done in the past, while meeting the growing digital requirements within their budget constraints. Meanwhile, new, online-only entrants are making a bet that their future banking clientele do not require any physical presence, particularly in the millennial market.
This blog delves deeper into the strategies and tactics being deployed by the first group, the large national players. With the financial wherewithal to invest in new technology, these institutions strive to provide the widest array of banking options and features to attract and retain customers, while also improving efficiencies within their companies.
As early adopters of online and mobile banking services, the national banking institutions enjoyed an advantage over their smaller competitors when the pandemic hit and physical access to bank branches became limited. Not surprisingly, the J.D Power 2020 Retail Banking Satisfaction Study found that these large financial institutions had both a greater penetration of digital customers and a higher customer satisfaction index of their customers, using more advanced online and mobile capabilities to achieve this advantage while increasing revenues, managing costs and improving service.
Many large national banks have increased revenues and grown market share largely by focusing on customer experience as an essential component in attracting clients from large and small competitors alike. By increasingly using human-centered design techniques and mobile banking services to tailor technology to the needs of the customer base being served, these banks have rolled out highly effective online and mobile platforms that leave customers feeling good about their experience. This approach often includes faster onboarding, simplified payment processing, and easier access to account and transaction information with digital signatures and mobile check deposits reducing the need to come to a branch to create a new account or conduct many common transactions.
Reducing foot traffic into branches has not reduced the ability to grow revenues by selling more products, however, as the national players have increasingly leveraged artificial intelligence to mine their data to determine which customers are likely candidates to purchase certain products, and then following up with targeted online marketing campaigns to promote those products and make signing up quick and easy via online banking.
Despite the obvious technology costs of deploying digital banking capabilities, the large players have found ways to use digital banking to reduce two of their largest expenditures: labor costs and fraud losses. Like most companies, the largest expense for a bank is their human capital costs. Technology has successfully enabled the large financial institutions to serve more customers with fewer employees.
Using robotic process automation, more and more activities previously performed manually by bank staff are now computerized. Chatbots and Voice Assistants are also being used to allow customers to get answers to questions or to process certain transactions with less need for interaction with a human employee. As an example of the magnitude of this labor cost reduction, in an interview with CNBC in October, 2020 Brian Moynihan, CEO of Bank of America (BofA), stated that through the adoption of technology, BofA has reduced its workforce in the past decade from 288,000 people to 204,000, a 29% decrease.
While the increased use of digital banking has led to efficiency in bank operations, it has also increased the risk for bank fraud. Online and mobile banking provide new gateways for criminals to defraud businesses and consumers. Fortunately, artificial intelligence and machine learning platforms have provided a means to combat these criminal activities and reduce the losses associated with bank fraud. As the sophistication of these systems have grown, they have become more equipped to recognize emerging trends and behaviors to identify additional transactions of concern. In the past, one common mechanism to mitigate risk of a potentially fraudulent transaction was to simply deny an application. Today, using artificial intelligence, fraud losses are being mitigated with less impact to approval rates.
Finally, with respect to improving service, a growing trend particularly popular among younger customers is the concept of digital self-service. Self-service is the ability for customers to get answers to questions and process transactions without the need to wait for a service representative to help them. According to Salesforce’s “State of the Connected Customer”, 59% of consumers and 71% of business buyers say self-service availability positively impacts their loyalty.
Features like Frequently Asked Questions (FAQs), videos about banking products, or financially-related knowledge articles have been added to bank websites and mobile apps as part of this self-service. Combined with Chatbots and Voice Assistants mentioned above, customers are now getting the answers they are looking for much quicker than they were when waiting for a customer service representative on the phone.
These digital banking technology investments have provided the large financial institutions a strategic advantage over their smaller, less well-healed competitors. So, what are these community banks and credit unions doing to counter this advantage? Stay tuned for my next blog in this series.
In the first installment of our Product Owner Empowerment series, we talked about the three crucial dimensions of ‘Knowledge’ that affect a Product Owner’s effectiveness. This post is going to take a deeper dive into the impact Empathy has on a Product Owner’s ability to succeed.
Empathy: Assuming positive intent, empathy is something that comes naturally to a person. However, environmental factors can influence a person’s ability to relate or connect with another person or team. Let’s explore some aspects of empathy and how they may impact a Product Owner’s success.
- Empathy towards the team(s): To facilitate an empathetic relationship between a Product Owner and the team, the PO must be able to meet the team where they are (literally and figuratively). Getting to know the team members and building a rapport requires the Product Owner to extensively interact with the team and proactively work to build such relationships. Organizations should facilitate this by making sure Product Owners are physically located where the team is and is empowered to not only represent the team to the business but also play the role of protector from external interruptions, so that team can function effectively. As alluded to above, having a good understanding of what it takes to deliver, helps tremendously with the ability to place themselves in the team’s shoes and see things from their perspective.
- Empathy towards the customer(s): It is easy to assume that a Product Owner acting on behalf of the business will automatically have empathy and an understanding of their needs to adequately represent their business interests. However, organizational culture can sometimes influence how a Product Owner prioritizes work. If it is only the sponsors directing the team’s scope and prioritization, a critical element of customer input is missed. Product Owners should place sufficient emphasis on obtaining customer opinion and feedback to inform the direction of product development.
- Empathy in the Organization: This factor relates to the organizational culture. As companies embrace Agile and expect its benefits to be equally realized, more emphasis on the desire to be lean begins to form. While being lean is a goal every organization should have, it is important to understand what kind of impact a lean organization has on individual teams or team members. A systemic push to be lean, in combination with less than optimal Agile maturity and the presence of antipatterns, can lead to teams being held against unsustainable delivery expectations. This problem is more common than you would think. Most organizations are going through some level of Agile transformation, but leadership expectations of benefits realization are always a few steps ahead of where the organization truly is on the Agile journey. Having the right set of expectations and the empathy necessary to reset them based on continuous learning and feedback is needed at an organizational level.
Check back next week to see how a Product Owner’s success is tied to psychological safety for themselves and the teams they are working with.
If you are a Product Owner or your Agile team struggles with this role, you won’t want to miss our upcoming webinar on Product Owner Empowerment. This webinar will be held on December 15th and you can register today here! Space is limited and on a first-come basis.
The Product Owner plays a crucial role in the success of a team and subsequently the organization. Most organizations consider the Product Owner to be a person with sufficient business knowledge such that they can communicate the business needs to the teams for implementation. While this is an important qualifier for a Product Owner, other factors must be present to have a truly empowered Product Owner.
The following 3 factors have the biggest impact on a Product Owner’s ability to succeed:
- Psychological Safety
These factors are not just applicable to the Product Owner, but also the surrounding environment. This includes the organization, processes, culture, teams, the product itself, stakeholders, and customers. Let us dig a little deeper.
In this post, we are going to focus on the first influencer: Knowledge. Next week, we’ll take a deeper dive into the impact Empathy has on a Product Owner’s ability to succeed, and we’ll round out the series with defining Psychological Safety and looking at the effect it has on a Product Owner.
Knowledge: The knowledge aspect is the most obvious and widely analyzed and assessed factor to evaluate the effectiveness of a Product Owner. However, there are several dimensions of knowledge that are required.
- Domain Knowledge: This dimension doesn’t need explaining and is probably the most obvious one of all. The Product Owner must have a good understanding of the domain they are working in, to effectively lead product development. While it may seem comfortable to assume that industry-wide it is common practice to have Product Owners with sufficient domain knowledge, some Agile antipatterns have led to the emergence of roles such as proxy Product Owner, or technical Product Owner. The primary culprit for organizations gravitating to this antipattern is a lack of understanding of the Product Owner’s role. Organizations assume that as long as there is a communication path to transfer the business needs to the teams, it is ok to have layers between the customer and the team. This creates dysfunction in Agile teams that are supposed to collaborate with the Product Owner in discovering and delivering value, but don’t have an empowered Product Owner who can make decisions and pivot when needed effectively.
- Process Knowledge: When it comes to a PO having knowledge and understanding of the Agile approach, best practices, and antipatterns usually takes a back seat. To clarify, we are not talking about just having your PO take a 2-day certification class and call it a day. Yes, it is necessary to have formal learning as part of role development, but, the learning should not remain at this minimal level. An effective Product Owner should have lived the process, learned from the challenges, successes, and failures, so they understand what it takes to deliver the product they are helping build
- Knowledge of PO role across in the organization: We talked about knowledge that a PO should have, but, to have a truly empowered Product Owner, an organization needs to know what to do with such a role. As mentioned before, a Product Owner role is different from a mere subject matter expert. To empower a Product Owner to make decisions, the organizational stakeholders need to understand how the Product Owner role works in an Agile context. Product Owners are not only the primary source of information on business needs for the team but are also one of the key roles influencing the pace of value delivery.
If the organization doesn’t understand what it takes for an Agile team to receive business needs Just-in-Time, iterate on requirements, let design emerge, deliver value and allow for slack time and innovation, It will make a Product Owner’s job quite difficult if they are still held to traditional expectations from leadership. These expectations may include providing inflexible delivery commitments, obtaining buy-in from a myriad of stakeholders before any scope changes are made, or worst of all, ensuring maximized utilization from the team. The organization’s stakeholders must be trained and knowledgeable about the basics of Agile if they are new to this way of working. Additionally, leadership must know the common pitfalls, assumptions, and antipatterns that organizations fall into and actively work to avoid or mitigate them.
If you are a Product Owner or your Agile team struggles with this role, join me for a free webinar on Product Owner Empowerment. This webinar will be held on December 12th and you can register here! Space is limited and on a first-come basis.
Agile 2 is here!
I was fortunate to be included in a group of exceptional Agile leaders and practitioners, led by Clifford Berg, to retrospect on Agile and improve upon what it has become over the last 20 years. Each of us began by citing issues and problems we have encountered over the years, drawing on our unique experiences. Not all of us experienced the same issues, but it was eye opening to discover what others came up with because of the diversity of the group both in practice and expertise.
We then discussed why we felt the problems occurred and what could be done to change them. This led us to revisiting the values and principles of the Agile Manifesto and many of the frameworks we use today. While I am vested in many of these, having become certified in them myself and trained others on them as well, I have seen where lack of clarity or difference of interpretation, as well as too much emphasis placed on prescription, leads to less than successful outcomes.
It is this clarity and thoughtfulness that Agile 2 seeks to deliver. It is a set of values and principles based on common problems that we believe will resonate with you, the Agile practitioner. My colleagues and I are proud of Agile 2 and the potential impact we believe it can have on the current state of Agile. Have we gotten it all right? Undoubtedly there is room for debate. Have we missed some valuable principles? Perhaps. And that is why we want Agile 2 to be open to ideas from the community, and there will be an Agile 2 version 1.1. We respect and welcome your input and ideas. We want Agile 2 to be constantly improving on what it is today so that it stays relevant. There will be Agile 2 community forums, and to begin that, there is a LinkedIn group. A book is on the way. The Agile 2 website is at https://agile2.net. Check it out!
In the previous blog, I had provided insights on what ZTA is, what the core components that belong to ZTA are, why organizations should adopt ZTA and what the threats to ZTA are. In this blog, I will go through some of the common deployment use cases/scenarios for ZTA using software defined perimeters and move away from enterprise network-based perimeter security.
Scenario 1: Enterprise using cloud provider to host applications as cloud services and accessed by employees from the enterprise owned network or external private/public untrusted network
In this case, the enterprise has hosted enterprise resources or applications in a public cloud, and users want to access those to perform their tasks. This kind of infrastructure helps the organization provide services at geographically dispersed locations who might not connect to the enterprise owned network but could still work remotely using personal devices or enterprise owned assets. In such cases, the enterprise resources can be restricted based on the user identity, device identity, device posture/health, time of access, geographic location and behavioral logs. Based on these risk factors, the enterprise cloud gateway may wish to grant access to resources like employee email service, employee calendar, employee portal, but may restrict access to services that provide sensitive data like the H.R. database, finance services or account management portal. The Policy Engine/Policy Administrator will be hosted as a cloud service which will provide the decision to the gateway based on the trust score calculated from various sources like the enterprise system agent installed on devices, CDM system, activity logs, threat intelligence, SIEM, ID management, PKI certificates management, data access policy and industry compliance. The enterprise local network could also host the PE/PA service instead of the cloud provider, but it won’t provide much benefit due to an additional round trip to the enterprise network to access cloud hosted services which will impact overall performance.
Scenario 2: Enterprise using two different cloud providers to host separate cloud services as part of the application and accessed by employees from the enterprise owned network or external private/public untrusted network
The enterprise has broken the monolithic application into separate microservices, or components hosted in multiple cloud providers even though it has its own enterprise network. The web front end can be deployed in Cloud Provider A, which communicates directly to the database component hosted in Cloud Provider B, instead of tunneling through the enterprise network. It is basically a server-server implementation with software defined perimeters instead of relying on enterprise perimeters for security. The PEPs are deployed at the access points of web front end and database components which will decide whether to grant access to the service requested based on the trust score. The PE and PA can be services hosted either in cloud or other third-party cloud provider. The enterprise owned assets that have agents installed on them can request access through PEPs directly and the enterprise can still manage resources even when hosted outside the enterprise network.
Scenario 3: Enterprise having contractors, visitors and other non-employees that access the enterprise network
In this scenario, the enterprise network hosts applications, databases, IoT devices and other assets that can be accessed by employees, contractors, visitors, technicians and guests. Now we have a situation where the assets like internal applications, sensitive information data should only be accessed by employees and should be prevented from visitors, guests and technicians accessing it. The technicians who show up when there is a need to fix the IoT devices like smart HVAC and lighting systems still need to access the network or internet. The visitors and guests also need access to the local network to connect to the internet so that they could perform their operations. All these situations described earlier can be achieved by creating user, device profiles, and enterprise agents installed on their system to prevent network reconnaissance/east-west movement when connected to the network. The users based on their identity and device profile will be placed on either the enterprise employee network or BYOD guest network, thus obscuring resources using the ZTA approach of SDPs. The PE and PA could be hosted either on the LAN or as a cloud service based on the architecture decided by the organization. All enterprise owned devices that have an installed agent could access through the gateway portal that grants access to enterprise resources behind the gateway. All privately owned devices that are used by visitors, guests, technicians, employee owned personal phones, or any non-enterprise owned assets will be allowed to connect to BYOD or guest network to use the internet based on their user and device profile.
Zero Trust Maturity
As organizations mature and adopt zero trust, they go through various stages and adapt to it based on the cost, talent, awareness and business domain needs. Zero trust is a marathon, and not a sprint, hence incrementally maturing the level of zero trust is the desired approach.
Stage 0: Organizations have not yet thought about the zero trust journey but have on-premises fragmented identity, no cloud integration and passwords are used everywhere to access resources.
Stage 1: Adopting unified IAM by providing single sign-on across employees, contractors and business partners using multi-factor authentication (MFA) to access resources and starting to focus on API security.
Stage 2: In this stage, organizations move towards deploying safeguards such as context-based (user profile, device profile, location, network, application) access policies to make decisions, automating provisioning and deprovisioning of employee/external user accounts and prioritizing secure access to APIs.
Stage 3: This is the highest maturity level that can be achieved, and it adopts passwordless and frictionless solutions by using biometrics, email magic links, tokens and many others.
Most of the organizations in the world are either in stage 0 or stage 1 except for large corporations who have matured to stage 2. Due to the current COVID situation, organizations have quickly started to invest heavily to improve their ZT maturity level and the overall security posture.
Draft (2nd 1) NIST Special Publication 800-207. Available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207-draft2.pdf
The State of Zero Trust Security in Global Organizations
Effective Business Continuity Plans Require CISOs to Rethink WAN Connectivity
Zero Trust Security For Enterprise Mobility
As we mentioned in our previous post, we are celebrating our 40th anniversary and, as part of our celebrations, we have created this 40 Years and Forward blog series. So, without further ado, welcome to the second posting in that series!
In our last blog, we took a stroll down memory lane and reminisced about CC Pace’s origins and what the world was like in 1980 when we were founded. While much has changed here at CC Pace and in the world in general (internet anyone?), we have been steady in our drive to meet the needs of our customers by providing valuable business solutions. Working with a national client base that ranges from tech start-ups to Fortune 500 companies as well as government entities – no company or project has proven to be too big or too small.
While we have remained consistent to our values and in our focus, another key aspect to our longevity has been our adaptability. For instance, CC Pace’s biggest client during our first year was the Department of Energy and we were deeply involved with the Oil and Gas industries. As we grew and our client base expanded, we shifted direction to the telecommunications and the financial services/mortgage industry. We focused our strategic planning on truly understanding how innovative technologies and methodologies work, and when and where to apply them. For example, back in 1999, when others were consistently using the waterfall approach, CC Pace started to think differently and used an Agile methodology, XP, for the first time on a custom software development project.
Our adaptability has also come into play as we have successfully navigated our way through many challenging times including the financial crisis of 2009 and most recently the coronavirus pandemic, we find ourselves in today. By seizing the opportunity to adapt to the market, investing in our people and discovering new technologies, CC Pace has successfully kept up with our clients’ needs. We are carrying that adaptability into 2020 as our development teams are currently creating mobile apps and working on cloud transitions and integrations. It is through these continued efforts and our ability to adjust to the market, that CC Pace has become a nationally recognized leader in Agile training and coaching, custom application development, financial and healthcare services consulting and IT staffing.
We invite you to stay tuned to our next 40 Years and Forward blog series in which we’ll share deeper insight into our company culture. And, how our team has thrived in a social, collaborative and productive environment that even encourages playfulness while at work!
“This isn’t a time to postpone your job hunt…” Yes, hiring may be slowing down, but it is not coming to a halt. There are many fulfilling jobs out there and now is the time to prepare yourself for that next great opportunity! This quick read outlines 5 job seeking strategies that will help put you ahead of your peers when this health crisis normalizes.
Taking the time to invest in yourself and completing a small job hunting task each day, will position you for success when hiring emerges to its normal feverish pace. Stay safe and healthy my friends and remember… be patient, persistent and most of all be flexible. #weareallinthistogether
I have a deep interest in cybersecurity, and to keep up with the latest threats, policies and security practices, I became a member of ACT-IAC organization and enrolled in the Cybersecurity Community of Interest group. This is where I got the opportunity to work as a volunteer in the Zero Trust Architecture Phase 2 project. Hence, I am trying to share the knowledge I gained around ZTA strategy and principles. I am planning to break my blog into four series based on how the project progresses.
- What is ZTA?
- Real world deployment scenarios
- ZTA core capabilities
- Vendors providing ZTA capabilities
What is ZTA and how did it come into existence?
Traditionally, perimeter-based security has been used to protect the network infrastructure behind a firewall where if the user gets authenticated, they can access all the resources behind the firewall assuming all network users/devices as trustworthy. This caused a lot of security breaches across the globe where attackers could move laterally and exploit resources to which they were not authorized. The attackers only had to get through the firewall and later crawl across any resource available in the network causing potential damage in terms of data loss and other financial implications that can come via ransomware attacks.
Currently, an enterprise’s infrastructure operates around several networks like cloud-based services, remote users connecting from their own network using their enterprise-owned or personal devices (laptops, mobile devices), network location can change based on where the users/devices are connected from for e.g. public WIFI, internal enterprise networks etc. All these complex use cases made the possibility of moving away from perimeter-based security to “perimeter less” security (not confined to one network infrastructure) which led to the evolution of a new concept called as “Zero-Trust” where you “trust no one, but verify”. ZT approach is primarily based on data protection but it can be applied across other enterprise assets like users, devices, applications and infrastructure.
ZTA is basically an enterprise cybersecurity strategy that prevents data breaches and limits lateral movement within the network infrastructure. It assumes all the internal or external agents (user, device, application, infrastructure) that wants to access an enterprise resource (internal network or externally in the cloud) is not trustworthy and needs to be verified for each request before granting access to them.
What does Zero Trust mean in a ZTA?
In the above diagram, the user who is trying to access the resource must go through the PDP/PEP. PDP/PEP decides whether to grant access to this request based on enterprise policies (data/access/risk), user identity, device profile, location of the user, time of request and any other attributes needed to gain enough confidence. Once granted, the user is on an “Implicit Trust Zone” where it can access all the resources based on network infrastructure design. “Implicit Trust Zone” is basically the boarding area in an airport where all the passengers are considered trustworthy once they verify themselves through immigration/security check.
You can still limit access to certain resources in the network using a concept called “Micro-Segmentation”. For example, after getting through the security check and reaching the boarding area, passengers are again checked at the boarding gate to make sure they are entering the authorized flight to reach their destination. This is what “Micro Segmentation” means where the resources are more isolated to a segment and access requests are verified separately in addition to PDP/PEP.
Tenets of ZTA: (As per NIST SP 800-27 publication)
All the resources whether its data related, or services provided should be communicating in a secure fashion irrespective of their network location. Each individual access request will be verified before granting access to any resource based on the client’s identity, device they are using to request, type of application used, location coordinates and other behavioral attributes. Each access request granted will be authenticated and authorized dynamically and strictly enforced. In addition, the enterprise should collect all activity information, log decisions, audit logs and monitor the network infrastructure to improve the overall security posture.
What are the logical components of ZTA?
Policy Engine: Responsible to make and log decisions based on enterprise policy and inputs from external resources (CDM, threat intelligence etc.) to grant access or not to a request.
Policy Administrator: Responsible for establishing or killing the communication path between the subject and enterprise resource based on the decision made by PE. It can generate authentication tokens for the client to access the resource. PA communicates with PEP via the control plane.
Policy Enforcement Point: Responsible for enabling, monitoring and terminating communication between subject and enterprise resource. It can be either used as a single logical component or can be broken into two components: the client agent and resource gateway component that controls access. Beyond the PEP is the “Implicit Trust Zone” to access enterprise resources.
Control Plane/Data Plane: The control plane is made up of components that receive and process requests from the data plane components that wish to access network resources. The control and data planes are more like zones in the ZTA. All the resources, devices, and users within the network can have their own control plane component within them to decide whether the data should be routed further or not. In this diagram, it is just used to explain how control plane works for data plane components. Data plane simply passes packets around and the control plane routes them appropriately based on decisions made.
Note: The dotted line that you see in the image above is the hidden network that is used for communication between the various logical components.
Why should organizations adopt ZTA?
When adopting a ZTA, organizations must weigh all the potential benefits, risks, costs, and ROI. Core ZT outcomes should be focused on creating secure networks, securing data that travels within the network or at rest, reducing impacts during breaches, improving compliance and visibility, reducing cybersecurity costs and improving the overall security posture of an organization.
Lost or stolen data, ransomware attacks, and network and application layer breaches cost organizations huge financial losses and market reputation. It takes a lot of time and money for an organization to resume back to normal if the security breach was of the highest degree. ZT adoption can help organizations avoid such breaches which is the key to survive in today’s world, where state funded hackers are always ahead of the game.
As with all technology changes, the biggest challenge to demonstrate higher ROI and lower cybersecurity costs is the time needed to deliver the desired results. Organizations should consider the following:
- Assess what components of ZTA pillars they currently have in their infrastructure. Integration of components with existing tools can reduce the overall investment needed to adopt ZTA.
- Consider including costs or impacts associated with risk levels and occurrences when doing ROI calculations.
- ZT adoption should simplify, and not complicate, the overall security strategy to reduce costs.
What are the threats to ZTA?
ZTA can reduce the overall risk exposure in an enterprise but there are some threats that can still occur in a ZTA environment.
- Wrongly or mistakenly configured PE and PA could cause disruptions to the users trying to access the resources. Sometimes, the access requests which would get unapproved previously could get through due to misconfiguration of PE and PA by the security administrator. Now, the attackers or subjects could access resources from which they were restricted before.
- Denial of service attacks on PA/PEP can disrupt enterprise operations. All access decisions are made by PA and enforced by PEP to make a successful connection of a device trying to access a resource. If the DoS attack happens on the PA, then no subject would be able to get access as the service would be unavailable due to a flood of requests.
- Attackers could compromise an active user account using social engineering techniques, phishing or any other way to impersonate the subject to access resources. Adaptive MFA may reduce the possibility of such attacks on network resources but still in traditional enterprises with or without ZTA adoption, an attacker might still be able to access resources to which the compromised user has access. Micro-segmentation may protect resources against these attacks by isolating or segmenting the resource using technologies like NGFW, SDP.
- Enterprise network traffic is inspected and analyzed by policy administrators via PEPs but there are other non-enterprise-owned assets that can’t be monitored passively. Since the traffic is encrypted and it’s difficult to perform deep packet inspection, a potential attack could happen on the network from non-enterprise owned devices. ML/AI tools and techniques can help analyze traffic to find anomalies and remediate it quickly.
- Vendors or ZT solution providers could cause interoperability issues if they don’t follow certain standards or protocols when interacting. If one provider has a security issue or disruption, it could potentially disrupt enterprise operations due to service unavailability or the time taken to switch to another provider which can be very costly. Such disruptions can affect core business functions of an enterprise when working in a ZTA environment.
[ACT-IAC] American Council for Technology and Industry Advisory Council (2019) Zero Trust Cybersecurity Current Trends. Available at https://www.actiac.org/zero-trust-cybersecurity-current-trends
Draft (2nd 1) NIST Special Publication 800-207. Available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207-draft2.pdf
NIST Zero Trust Architecture Release: https://www.nccoe.nist.gov/projects/building-blocks/zero-trust-architecture
Welcome to the first blog in our 40 Years and Forward anniversary series! All of us here at CC Pace love thinking back about where we have been, what we have accomplished and all the experience we have gained here at CC Pace, but we get even more excited thinking about where we are headed. That’s why we have decided that 40 Years and Forward is the perfect theme as we celebrate our 40th anniversary.
We will start at the beginning in this first blog and do a bit of that much beloved reminiscing, shall we? Did you know CC Pace was founded in 1980? It’s true. The very same year that Pac-Man was introduced, CNN was launched and the big topic around watercoolers across the country was “Who Shot JR?” (in case you don’t remember or possibly were not born yet, it was his wife Sue Ellen’s sister, Kristen). Anyway, 1980 was also the year during which CC Pace President and founder, Mike Gordon held an IT position with a financial services technology consulting firm called R. Shriver and Associates. When that firm decided to sell off their DC branch, Mike and some colleagues jumped at the opportunity to purchase it, and so as the story goes CC Pace was born.
Here’s another piece of trivia and a question we get asked quite often: Where did the name CC Pace come from? It’s a bit of a long story, but here goes, Mike and his colleagues decided on the name Cabot Consulting for their new company. Back then, Oil and Gas was the market that CC Pace’s focus was on and unfortunately, as Mike and his partners found out, there was a Fortune 500 oil and gas company that was named Cabot Corporation. So, in 1988, they went through the naming process again. The result was the name ‘Pace’. Since Mike was looking for a way to transition from the old name to the new name, and the general consensus was to also consider adding either a word or prefix/suffix that would distinguish us from all the other Paces out there, it was decided to incorporate the prefix of C.C. that would reference Cabot Consulting. Yes, we admit our naming story is not a simple one, but that is how we ended up with our beloved name of C.C. Pace (aka CC Pace).
Now that we have taken a little stroll down memory lane, we would like to invite you to stay tuned to our 40 Years and Forward blog series to see how we have adapted to change over the years and what our plans are for the future.
What is App Modernization
Legacy application modernization is a process to update existing and aging applications with modern architecture to enhance features and capabilities. By migrating your legacy applications, you can include the latest functionalities that better align with what your business needs to succeed. Keeping legacy applications running smoothly while still being able to meet current day needs can be a time consuming and resource intensive affair. That is doubly the case when software becomes so outdated that it may not even be compatible with modern day systems.
A Quick Look at a Sample Legacy Monolithic Application
For this article, say a decade and half year-old, Legacy Monolithic Application is considered as depicted in the following diagram.
This depicts a traditional, n-tier architecture that was very common in the past 20 years or so. There are several shortcomings with this architecture, including the “big bang” deployment that had to be tightly managed when rolling out a release. Most of the resources on the team would sit idle while requirements and design were ironed out. Multiple source control branches had to be managed across the entire system, adding complexity and risk to the merge process. Finally, scalability applied to the entire system, rather than smaller subsystems, causing increase costs for hardware resources.
We define modernization as migrating from a monolithic system to many decoupled subsystems, or microservices.
The advantages are:
- Reduce cost
- Costs can be reduced by redirecting computing power only to the subsystems that need it. This allows for more granular scalability.
- Avoid vendor lock-in
- Each subsystem can be built with a technology for which it is best suited
- Reduce operational overhead
- Monolithic systems that are written in legacy technologies tend to stay that way, due to increased cost of change. This requires resources with a specific skillset.
- Strong coupling makes it difficult to optimize the infrastructure budget
- De-coupling the subsystems makes it easier to upgrade components individually.
Finally, a modern, microservices architecture is better suited for Agile development methodologies. Since work effort is broken up into iterative chunks, each microservice can be upgraded, tested and deployed with significantly less risk to the rest of the system.
Legacy App Modernization Strategies
Legacy application modernization strategies can include the re-architecting, re-factoring, re-coding, re-building, re-platforming, re-hosting or the replacement and retirement of your legacy systems. Applications dating back decades may not be optimized for mobile experiences on smartphones or tablets, which could require entire re-platforming. Lift and Shift will not add any business value if you migrate legacy applications just for the sake of Modernization. Instead, it’s about taking the bones, or DNA, of the original software, and modernizing it to better represent current business needs.
Legacy Monolithic App Modernization Approaches
Having examined the nightmarish aspects of continuing to maintain Legacy Monolithic Applications, this article presents you with two Application Modernization Strategies. Both listed below will be explained at length to get basic idea on to pick whatever is feasible with constraints you might have.
- Migrating to Microservices Architecture
- Migrating to Microservices Architecture with Realtime Data Movement (Aggregation/Deduping) to Data Lake
In this section, we shall take a dig at how re-architecting, re-factoring and re-coding per microservices paradigm will help avoid a lot of overheads of maintaining a legacy monolithic system. The following diagram helps you better understand Microservice Architecture – a leap forward from legacy monolithic architecture.
At a quick glance of above diagram, you can understand there is a big central piece called API Gateway with Discovery Client. This is comparable to a Façade in a Monolithic Application. API Gateway is essentially an entry point to access several microservices which are comparable to modules in Monolithic Application and are identified/discovered with the help of Discovery Client. In this Design/Architecture of Microservices, API Gateway also acts as API Orchestrator as it resorts to one Database set via Database Microservice in the diagram. In other words, API Gateway/Orchestrator orchestrates the sequence of calls based on the business logic to call Database Microservice as individual Microservices have no direct access to database. One can also notice this architecture supports various client systems such as Mobile App, Web App, IOT APP, MQTT App et al.
Although this architecture gives an edge to using different technologies in different microservices, it leaves us with a heavy dependency on the API Gateway/Orchestrator. The Orchestrator is tightly coupled to the business logic and object/data model, which requires it to be re-deployed and tested after each microservice change. This dependency prevents each microservice from having its own separate and distinct Continuous Integration/Continuous Delivery (CI/CD) pipeline. Still, this architecture is a huge step towards building heterogenous systems that work in tandem to provide a complete solution. This goal would otherwise be impossible with a Monolithic Legacy Application Architecture.
Microservices Architecture with Realtime Data Movement to Data Lake
In this section, we shall take a dig at how re-architecting, re-factoring, re-coding, re-building, re-platforming, re-hosting or the replacement and retirement of your legacy systems per microservices paradigm will help avoid a lot of overheads of maintaining a legacy monolithic system. The following diagram helps you understand a complete advanced Microservices Architecture.
At the outset, most part of the diagram for this approach looks like the previous approach. But this adheres to the actual Microservice paradigm more than the previous. In this case, each microservice is individual and has its own micro database of any flavor it chooses to be based on the business needs and avoids dependency on a microservice called database microservice or overload API Gateway to act as Orchestrator with business logic. The advantage of this approach is, each Microservice can have its own CI/CD pipeline release. In other words, a part of application can be released with TDD/ATDD properly implemented avoiding costs incurred for Testing/Deploying and Release Management. This kind of architecture does not limit the overall solution to stick to any particular technical stack but encourages to provide quick solutions with various technical stacks. And gives flexibility to scale resources for highly hit microservices when necessary.
Besides this architecture encourages one to have a Realtime Engine (which can be a microservice itself) that reads data from various databases asynchronously and apply data aggregation and data deduping algorithms and send pristine data to Data lake. Advanced Applications can then use the data from Data lake for Machine Learning and Data Analytics to cater to the business needs.
Note: This article has not been written any cloud flavor in mind. This is general App Modernization Microservices architecture that can run anywhere on-prem or OpenShift (Private Cloud) or Azure Cloud or Google Cloud or AWS (Private Cloud)
It’s that time of the year when we get together with friends for fun, good food and some friendly rivalry. That’s right, it’s Superbowl weekend and we here at CC Pace decided to kick it off early with a Jeans and Jersey day! Although we have nothing but love and respect for both the Chiefs and the 49ers, we didn’t want to exclude any form or flavor of team spirit. So, we opened the jersey wearing to any team, in any sport. And, Pacers did not disappoint! People joined in on the fun and showed up in an array of team attire and we shared a field of treats!
We decided we needed to add some competition to our festivities and played a Superbowl word game and guess who the big winner was…CC Pace president, Mike Gordon – Way to go Mike! (and, no we did not let him win because he is the president, we are all way to competitive for that!)
You may notice in the pictures that there was a clear shortage of the Superbowl’s colors, but everyone did have a clear pick on a winner for the big game. The majority of us are rooting for the Kansas City Chiefs, and not just because they haven’t won a Superbowl since 1969 (well, maybe that’s part of it). Go Chiefs!
We recently conducted a (sold out!) webinar on the LIBOR Transition, driven by the NY DFS sending a letter to over 1,000 companies that they regulate Board of Directors, with a response due on March 23, 2020.
The first question we received in response to the webinar was “you guys use a lot of acronyms, can you explain what it means, please?” And it’s true, we do use a lot of terms, so we put together a LIBOR transition cheat sheet (a Glossary) to explain not only what each acronym means, but why it is important in a LIBOR transition context.
Some facts about LIBOR:
- LIBOR has been in use since the 1970’s and is well understood by the markets and regulators.
- Many loans use LIBOR as an index rate, especially mortgages and student loans.
- However, dollar volume of LIBOR based contracts, futures, options, or other types of derivatives is far greater than its use in loans.
- Although people talk about it as if it were a single number, it actually has its own “Term Structure” (see our glossary) with 7 different rates and its own yield curve. Having a Term Structure is a great attribute for a Reference Rate to have, and most Alternative Replacement Rates do not have that, at least not yet.
- The Financial Conduct Authority (FCA, below) that oversees the publication of LIBOR decided in 2017 to not compel any bank to contribute to the LIBOR process after December 31, 2021. This means it is very unlikely that banks will participate after this date, and LIBOR will cease to be credible if it exists at all.
- Liquid markets require many participants. Therefore, regulators and associations are issuing Replacement Guidance to move participants to a new market. In the US, the ARRC (below) is guiding markets towards SOFR (below).
Here are the first four LIBOR-related acronyms you’ll hear us mention when we talk about the transformation. The full list of terms can be found here. It will be updated on a regular basis.
The primary goal of Marine Toys for Tots is to help bring the joy of Christmas through the gift of a new toy and send a message of hope to America’s less fortunate children. To join in this amazing effort, CC Pace signed up to be donation center for a second year in a row. Our employees shined with generosity and holiday spirit by overflowing our donation boxes! Not only did they provide games, dolls, books, cars, scooters and toys, but a group of them even took time to go out and shop together for our corporate donation – and as our video shows, had a blast while doing so! Here’s to Toys for Tots for celebrating their 72nd year in spreading joy!
The holiday season brings with it a flurry of fun activities, things like, gatherings with family or friends, taking part in treasured traditions and eating special dishes (there is always so much food!). With all those things in mind we have decided to kick off the holiday season with a festive and fun blog where we surveyed the CC Pace team to find out what they enjoy most during this time of year. So, without further ado, here’s a little insight on what our team enjoys most about the holidays:
What is your favorite holiday dish (excluding dessert)?
Stuffing was the #1 answer with 49% of CC Pacers in agreement! Looks like we have a lot of carb lovers, and they like a variety of stuffing. The answers varied from “inside stuffing” to “chestnut stuffing” to “cornbread stuffing” and just the classic “stuffing”. So, let’s hear it for stuffing!!
Which outdoor winter activity do you enjoy most?
- Building a snowman – 5%
- Skiing, Snow Tubing and/or Sledding – 40%
- Shoveling snow – 0% (hey, some people like shoveling snow – right?!)
- None, I like to stay inside and watch the snow from there – 55%
Apparently, staying cozy and warm inside is the priority for most of our team on a snowy day! Speaking of snow, here’s an interesting fact for those who live in the DC area: this year local forecasters are calling for a total snowfall of 10-16 inches inside the beltway, and 15-25 inches outside. Let’s all look back here in April and see how well their predictions held up!
What is your favorite holiday movie?
When it comes time to sit back and relax our team clearly goes for the comedies, with Love Actually and Christmas Vacation tying for the #1 favorite holiday movie, to which we can only say “yes, please”!
Which method do you prefer for holiday shopping?
- Shopping online – Amazon Prime all the way! – 68%
- Going to mall – I like the hustle and bustle of the crowds and grabbing my Starbucks! – 32%
Do you have a charitable organization or volunteering opportunity that you like to attend/favor during the holidays? If so, which one?
Our employees are very generous year-round, and this season is no different. Here are the Top 5 charity organizations they will be supporting during the holidays:
- Toys for Tots seems to be the most popular charity at this time of year amongst our team. That is great news for us since this year CC Pace is again participating as a collection center for the Marine Toys for Tots Program. Toys for Tots was started in 1947 and distributes an average of 18 million toys to 7 million less fortunate children annually. All are welcome to drop off toys at our headquarters through December 13th!
- Wreaths Across America
- SOME (So Others Might Eat)
- St. Jude Children’s Research Hospital
- Tie – several local shelters and children’s charities.
Eggnog or Hot Chocolate?
Hot Chocolate by a landslide – 75%.
What is your favorite Christmas carol or holiday song?
All I Want for Christmas Is You, by Mariah Carey, was released in 1994 and quickly rose to the top of the charts; it is the most downloaded Christmas song of all time. Ms. Carey said when recording this song that she wanted to create a classic, and that she certainly has accomplished!
From CC Pace to all of you, have a happy holiday season full of good cheer and best wishes for the new year!
One of our very own just celebrated this big milestone and rather than just giving you the 411 on it all, we’d like to change things up a bit and play a guessing game with you! If you’d like to play along keep reading, and no peeking at the pictures below. So, can you guess who it is? No? Well it is probably a bit hard given that CC Pace’s employees have an average tenure of 12+ years of service, so we figured we would give you some other clues to help you narrow down your guess:
Clue #1 – This person is a favorite amongst both those of us as CC Pace and our clients.
Clue #2 – This person speaks fluent Russian.
Clue #3 – This person recently obtained their AWS Practitioner certification.
Clue #4 – This person has musical talent and plays the bass.
Clue #5 – This person is also a skilled tennis player.
Still haven’t figured it out? then let’s keep going… Joining CC Pace in 2004, this person was part of the mortgage technology offering LOS Advantage. After working on various projects for us, they began working at the Municipal Securities Rulemaking Board (MSRB) on the EMMA product, and have been there for over 10 years. During their time at MSRB, they have been consistently praised for their ability to deliver what is asked of them, and always delivering on time.
Need another hint? Now our team lead at MSRB, they constantly work on building their technical skills, learning and adapting to different methodology frameworks, and working very well with people (seriously, everyone loves working with this person). The leadership at MSRB epitomizes the type of client partnership we strive for, one built on value, trust and all-around success, and is due largely to this individual.
Ready for the big reveal??
Please join us in congratulating Leo Belenky for his 15 Year Anniversary at CC Pace. Our president, Mike Gordon presented Leo with his service award and highlighted how his hard work and dedication are vital to the success of our organization. Thank you Leo, for 15 wonderful years of service! And, to our readers, thank you for playing along!
I recently attended a Data Connectors Cybersecurity strategies conference in Reston, VA. Companies practicing various security solutions had speakers’ sharing knowledge about security threats that are currently affecting the market and how to protect an IT organization against such attacks. Interestingly, Sophos speaker Paul Lawrence (cybersecurity sales engineer) discussed Ransomware as a Service (RaaS) and how to protect against these attacks. Below you will find the high-level information that I gathered in this conference which I feel will help others who are unaware of this threat.
P.S. – This is just an informatory blog on what RaaS is and how to prevent IT organizations from this attack.
What is Ransomware as a Service?
In layman’s term, RaaS is an unusual type of software as a service provided over the internet by criminals to attack IT systems and get paid ransom for it.
In 2018, 53% of the organizations were hit by ransomware and 1/3 of them paid ransom to recover from the ransomware attack.
How it works?
Suppose I am the bad guy who wants to hack machines, data, information but doesn’t want to reveal the identity and, I want to get paid ransom for hacking.
I can use RaaS (Ransomware as a Service).
I need to register my account by providing the bank details where I want to be paid the ransom. All my information that I provide to this service platform will be safe and it won’t be tracked (presumably).
Next, I download the viruses from this service platform and start infecting machines. Once infected, I can provide details about where they can pay the ransom to recover from the attack.
Now anybody can be a hacker using this RaaS service since malicious actors have created various models to attack any IT system. All you need is to follow the guidelines they provide with step by step details.
How do RaaS providers make revenue?
They will collect ransom from the organizations or individual vendors who were attacked through RaaS account payment system. Once they get paid the full ransom, a share of that money goes to the criminal who initiated this account payment by registering for this service.
Basically, a win-win situation for both the RaaS provider and the malicious actor who used this service to attack the IT system of the organization or individual vendors.
Types of Ransomware attacks
- Traditional ransomware attack: The attack is automated and doesn’t need manual intervention. It can spread rapidly across the globe. WannaCry is the most widely known traditional ransomware variant that infected nearly 125,000 organizations in over 150 countries.
- Targeted ransomware attack: This is a well-planned manually targeted attack by attacking the network and computers on the network. RobbinHood variant was used in the Baltimore ransomware attack which compromised most of Baltimore’s government computer systems. 13 bitcoins was the ransom demanded to unlock the computers.
Prevent from Ransomware attacks
Ransomware attacks are getting more targeted. One of the primary attack vectors for Ransomware attacks is Remote Desktop Protocol (RDP)
- Lock down RDP
- Use Strong passwords.
- Do not disable Network Level Authentication (NLA), as it offers extra authentication level.
- To learn more, please go to Malwarebytes Labs.
- Patch to prevent privilege elevation
- Limit the users to those that really need it
- Secure your network both from the outside and inside
- Disaster Recovery plan or Aftermath of an attack
- We need to ask this question to ourselves “Do we really need remote access?”
Selfie taken at the Data Connectors cybersecurity event 😊
Are you a seasoned Agile Practitioner interested in expanding services beyond yourself while providing strategic guidance to a variety of clients?
CC Pace is currently looking for a dynamic Agile Thought Leader who is ready to make an immediate impact and drive our Agile transformation services. The ideal candidate is local to the DC metro area, is comfortable making decisions and implementing innovative ideas. CC Pace will provide a flexible working environment and support interest in growing a personal reputation in the global Agile community, in addition to a competitive, comprehensive suite of benefits.
What will an Agile Thought Leader at CC Pace do?
- Set the direction for our Agile transformation services, drive strategic imperatives, define Agile offerings, establish priorities and grow our Agile business
- Represent CC Pace at conferences, through independently orchestrated thought leadership and by guiding client engagements
- Provide strategic guidance to clients through enhancing, producing and delivering Agile training and coaching both in person and via alternative delivery modes
- Build and mentor a team of consultants to deliver the services both with internal staff and business partners
- Define and brand CC Pace while developing new relationships in the Agile community
- Current certified Agile credentials or equivalent level of experience
- Strong communication and presentation skills – must be versed at public speaking and a capable writer
- Proven experience leading Agile engagements, including developing training materials and coaching at both the enterprise and team level
- Ability to demonstrate leadership experience in IT delivery, including building and sustaining high-performing teams
- Strong leadership skills that will support setting the direction for our Agile practice, managing a team of resources and driving the Agile offering and delivery strategies
- Ability to provide ample thought leadership to further our footprint in the Agile community
- Strong business acumen that will assist in supporting the sales & marketing efforts involving Agile transformation services
At CC Pace we have a strong referral program and encourage not only our employees but even those who don’t work for us to take advantage of it – so if you know someone who would be a fit for this position please refer them!
For more information regarding this Agile Thought Leader position, please contact Rechelle Card, email@example.com
For CC Pace’s 2nd quarter community outreach event, we collected personal care items in support of the Katherine K. Hanley Family Shelter (KHFS). KHFS is located in Fairfax, right around the corner from our office!
Thanks to everyone who participated. We were able to collect and put together “Care Kits” for 15-20 children, 10-12 women and 10-12 men. These Care Kits were comprised of items such as tooth paste, shampoo, conditioner, body wash and a tooth brush. These items will go to the families and individuals in need at the Katherine K. Hanley Family Shelter.
KHFS opened in 2007 and was the first emergency shelter in Fairfax County to adopt a rapid re-housing approach – an approach that was so successful, it has been incorporated into all emergency shelters in Fairfax County. Currently, KHFS houses 72 people, 45 of which are children. KHFS is part of the Shelter House organization.
Shelter House is a community-based, non-profit organization that provides crisis intervention, safe housing, and supportive services to homeless families and victims of domestic violence in our community. Shelter House was formed in 1981 as a grassroots responder to the homelessness crisis in Fairfax County. Shelter House is comprised of 3 emergency shelters: the Katherine K. Hanley Family Shelter, Artemis House and the Patrick Henry Family Shelter.
In the past year, across all programs, Shelter House served over 2,300 individuals, more than half of which were children. Of the families that exit Shelter House, nearly 70% move to permanent housing.
Thank you to everyone for your support and participation!
If you would like to learn more about Katherine K. Hanley or Shelter House, follow the link below:
There is a great team of people who work at CC Pace. We took a few minutes to get up close and personal with George Perkins, Ron Peterson and Suzie Wheeler, three of the people whose roles are front and center with our clients and candidates.
George is a Practice Manager who has just celebrated his 25th anniversary with CC Pace. George is responsible for the management of several of our client accounts and staff augmentation services. His primary focus in on the financial services and healthcare industries. Always the jokester, George is never one to miss the opportunity for a good one-liner during a meeting! Connect with George on LinkedIn.
We asked George some questions, and here’s what he had to say:
- Do you participate in some community outreach you would like to highlight? At CC Pace we believe in giving back to the community and participate in multiple events each year. Over the past few years I’ve been involved with the Ronald McDonald house, Homestretch’s backpacks for school kids, and sponsoring local families for Christmas. Also, I enjoy helping out with the local animal shelter.
- What professional groups do you belong to and what professional events do you attend? I attend NVTC events, Agile DC, and belong to WARN (Washington areas recruiters’ network) and ASA (American Staffing Association). I also represent CC Pace at job fairs and other IT conferences.
- What is your favorite…
- Food? Almost anything Asian, love the spices.
- Movie? Pulp Fiction and American Beauty
- Book? On the Road
- Team? Redskins
- Quote? “It’s just a flesh wound”
- Dog or Cat? Dog
- If you could do Carpool Karaoke with any singer living or dead, who would it be and why? Neil Young, I love his music and would be interested in talking to him about the days living in Laurel Canyon in the mid/late 60’s when all the great music/musicians were hanging out there.
Ron is our Senior Practice Manager for Federal Business Development. He focuses on building relationships and networking with government agencies on the local, state and federal level. Ron is probably one of the most easy-going people in the office. His calm demeanor and willingness to help out make working with him a true pleasure. Connect with Ron on LinkedIn.
So, Ron, tell us …
- Do you participate in some community outreach you would like to highlight? For 30 years, I have been volunteering in Federal and State prisons and local jails. Currently I am volunteering at Fairfax County Adult Detention Center.
- What professional groups do you belong to and what professional events do you attend? I belong to ACT-IAC and National Contract Management Association (NCMA). I also attend various conferences and industry events representing CC Pace.
- What is your favorite…
- Food? Seafood
- Movie? The Invisible Guest
- Book? The Bible
- Team? Yankees, Giants, and Golden State Warriors
- What is your hidden talent? Chess and Bid Whist (Bid Whist is an exciting, popular partnership trick-taking game. It is played with a standard 52 card deck plus 2 jokers, for a total of 54 cards).
Suzie is our Talent Acquisition and Recruiting Manager. She is responsible for the on-going strategy to find employees for the company with specific skillsets and recruiting for our clients’ technical positions. Suzie is always smiling, happy and has a pep to her step. She brings her positive attitude and enthusiasm to the entire CC Pace team. Connect with Suzie on LinkedIn.
Other fun facts about Suzie are:
- What professional groups do you belong to and what professional events do you attend? I belong to Women in Technology, SourceCon, and Project Save. I attend multiple events for various technical meet-up groups in the DC area, technical job fairs and agile conferences.
- What is your favorite…
- Food? Mexican, Maryland Blue Crabs, Spicy foods
- Movie? It’s hard to say just one, The Bucket List, Pay it Forward, The Notebook, Green Book
- Book? Disclosure by Michael Crichton, and The Secret by Rhonda Byrne
- Team? Dallas Cowboys and University of South Carolina teams
- Quote? “In the midst of movement and chaos, keep stillness inside of you” ~ Deepak Chopra
- Dog or Cat? Definitely dog
- If you could witness any historical event, what would you want to see? Probably witnessing the life of Jesus, I have so many questions about the events of this timeframe.
Our recent quarterly meeting made for a fun afternoon and evening for everyone. We had a lively staff meeting with presentations, service awards and team building activities, followed by a festive gathering at Dave & Busters.
At CC Pace, we’re lucky to have so many tenured employees. As our team members celebrate their CC Pace anniversaries, they are recognized by their colleagues and leadership team for their contributions throughout the years. We kicked off our service awards recognizing Chris Soule, Technical Consultant, for his 5 year anniversary with CC Pace. Chris was hired for an opening we had on our development team for MSRB. His success with this client continues today, where he has become a key leader on the EMMA project working not only on the data base side, but also helping to revamp the user interface. Per our client, Chris is the epitome of a team player! Chris, may you continue to inspire us for many years to come!
George Perkins, Practice Manager, was recognized for celebrating his 25th anniversary with us! George was hired as our first full-time recruiter. Over the years, as the staffing area of the business has evolved, he moved into the role of an Account Manager for some of our major clients. George’s philosophy has always been work hard towards success and have fun while you’re doing so – and he does just that! George, we thank you for your energy, enthusiasm and corporate commitment!
To take advantage of the rare moments our people are actually all together, we used this time to engage in some team building activities that were facilitated by Debbie Shatz, Sudhindra Shetty and the “always up for a good time”, George Perkins. Divided into 5 teams with red Solo cups in hand, our staff took aim at various building and stacking tasks (and, did we mention there were prizes)! Lots of cheering and yelling lead to some pretty hilarious bragging rights by the winners!
EAT. DRINK. PLAY. We kept the party going and had everyone move over to the new Dave & Buster’s in Fair Oaks Mall for an entertaining evening! There was food, drinks, billiards and of course lots more games and plenty of, should we say friendly competition. Together everyone enjoyed some good old fashioned laugh-out-loud fun!
The new URLA is coming. But the status report, for July 2019, is decidedly Red.
Warning signs regarding the immensity of the forthcoming changes have been out for well over a year, yet it seems some lenders are just starting to realize the size and implications of the coming changes related to the new loan application – the Uniform Residential Loan Application (URLA, aka 1003 or form 66). This is the first of a short series of blogs exploring the benefits and challenges that lie ahead.
The URLA is undergoing a total redesign for the first time in 30 years and that is driving major changes in four areas:
- The application itself – its form, data elements, organization and fundamental operation
- Its corresponding data file, the Uniform Loan Application Dataset (ULAD)
- The agencies’ automated underwriting systems (DU, Fannie Mae’s Desktop Underwriter and LP, Freddie Mac’s Loan Prospector) submission, interfaces and files
- The retirement (at least not keeping current) of the Fannie Mae DU3.2 file, which has long been the industry de facto standard for transferring data.
The optional date is coming soon – July 1, 2019 – and the required date is February 1, 2020 – not very far away for a truly major change.
When the subject of the new ULRA came up at the recent National Advocacy Conference, a gentleman sitting at my table said, “My vendor is taking care of it.” When he didn’t smile and the rest of us figured out that he was serious, the branch manager and the lawyer at my table both asked him “You mean your vendor sets your policy for how to fill out the language preference and whether you let the MLO do that instead of the borrower?”
I saw two other issues myself, including “Which vendor?” and “Are all your counterparties ready? Does your entire process work end-to-end?”
On the issue of leaving things to your vendor, even small lenders are likely to be dealing with two or more vendors who not only have to be ready, their systems have to be tested together to make sure that your process works.
Below is a simplified snippet taken from CC Pace’s Reference Architecture, showing internal interfaces that are affected by the new URLA:
That’s a lot of moving parts undergoing substantial change that need to continue to work together. Let’s look at things from the perspective of relatively common test cases. It seems reasonable to expect that a POS submission to DU and an LOS submission to DU will both work. But in an equally common, but decidedly more complex scenario, when you take the application on the POS, transfer the loan to the LOS, where you rerun DU and then request a set of documents from your doc vendor, it’s not hard to imagine that initially something will break down, simply based off of different assumptions that were made.
On the issue of counterparty readiness, the reference architecture reveals even more counterparties and vendors that have to be ready and that you will have to test your process with:
But wait, there’s more! As far as the industry is concerned, not only do you and your counterparties have to be ready, but the entire ecosystem has to be ready, end-to-end. And the status for that is decidedly red.
Take the previous difficult test case and now extend it to a common industry chain. A broker starts the application, it closes with a mortgage banker who then sells it to a correspondent investor, who now runs Early Check or LQA on it, purchases it from the mortgage bank and then delivers it to Fannie or Freddie. It is known that this will not all work in July 2019.
Here is what I gleaned from the MBA ResTech call from May 16th, 2019:
- Many individual vendors appear to be ready – but what that means is that they are ready to be tested in conjunction with other counterparties in the ecosystem
- Not all components necessary for an agency correspondent transaction are ready
- Correspondent Purchasers are starting to issue guidance that they will not purchase loans on the new URLA until 2020
It is CC Pace’s recommendation that every organization be extremely active monitoring the status of the new URLA both within and outside of their company; it is impossible that “our vendor is taking care of it all” is the right answer. This July through February represents a significant and much needed test period, not just for the systems and your process, but also for your compliance and training.
Some Correspondent Purchasers are issuing their own guidance on the matter. Have you?