Living in the digital age, it is not difficult to be familiar with a company’s name, reputation or logo – but do you really know what they do, and what they are all about? That got us thinking about our own company and we asked, what is it that people really want to know about CC Pace? So, we did some research with our team and came up with the Top 5 Most Asked Questions About CC Pace from our clients:
Where does the name CC Pace come from? (this is actually quite the story – so here we go…)
In the early 1970s, a financial services technology consulting firm headquartered in New Jersey named R. Shriver Associates (RSA) opened a Washington, DC branch as part of its growth strategy. In 1980, RSA management decided to sell the DC branch. Mike Gordon (current President of CC Pace) and several other employees bought the assets of the branch, and one of the immediate tasks was to come up with a name for the new company. A naming contest was initiated and the name that was selected was Cabot Consulting (we clearly didn’t hire a naming consultant). No person in the company was named Cabot, but, at the time, it conveyed a positive image as the Cabots were a prominent New England family.
In the 1980s, the vertical market that the company most served was Oil & Gas. Unfortunately, a Fortune 500 oil and gas company was named Cabot Corporation and they weren’t keen on sharing the Cabot name. So, in 1988, we went through a similar naming process as we did at the outset of the company. The result was a decision to call ourselves ‘Pace’. We thought it would convey us being forward thinking, and we also believed that we would be able to play on the word “pace” for marketing purposes. However, after finding conflicts with the Cabot name, we quickly realized that there would be 10 times more conflicts with the name of ‘Pace’. It was recommended that we add either a word or prefix/suffix that would distinguish us from all the other Paces out there. We were looking for a way to transition from our old name to the new name and someone suggested the prefix of C.C. from Cabot Consulting. Yes, it’s fairly convoluted, but that is how we ended up with our name being C.C. Pace (aka CC Pace).
Wait, we thought you are a training company?
While we have trained over 35,000 people in Lean-Agile disciplines over the last 15+ years, we actually got our roots in financial services consulting. Dating back to 1980, some of our earliest projects were in Loan Origination System Section and Technology Due Diligence for some of the leading players in the mortgage space (many of whom are still clients today).
Over the years, we grew our technical capabilities and were an early adopter of the Agile methodology. So, while we have dozens of training offerings under the Agile umbrella today – everything from Scrum Certification Courses, Kanban, SAFe, etc. – our sweet spot is actually Agile development. We launched our first Agile xP project in 1999, and four years later, adopted Scrum. In addition to our business and Agile transformation services, we also have a well-established IT Staffing team that works with a variety of clients in the DC area to find the right fit to help organizations meet their business objectives.
What kind of clients do you work with?
Our clients tend to be industry leaders who are looking for strategic business solutions that will enable them to focus on taking their business objectives to the next level. We generally align best with clients who view us as a partner and trust that we have a shared interest in success and doing what’s best – not just the fastest or cheapest option. We focus on long-term results and really try to look at what will be the best option(s) for both today and tomorrow, so clients that share that vision typically result in a dynamic partnership. With four decades of experience in the Financial Services sector, we clearly have a wealth of understanding in that arena, but we also have an array of knowledge and experience in the Healthcare industry. Many of our services can be applied across any industry, and our client base extends from Fortune 500 to start ups across a multitude of disciplines. You can learn more about our clients here.
Where are your offices located?
Our office is located in Fairfax, Virginia; however, our consultants work at client sites nationwide and we have employees who are based throughout the United States. We even have relationships with consultants in other countries to support some of our clients’ global offices and are well versed in supporting projects remotely as well.
What is it that makes CC Pace different than other consulting firms?
That’s a great question! CC Pace is a boutique consulting firm that is committed to providing top quality service to our clients and building long-term, strategic partnerships with them. We’ve been working with many of our clients for four decades, and we believe that these long-term client relationships clearly reflect our work ethic and our commitment to providing top-rate solutions. Over 80% of our new business is based on referrals, which tells us that we’re doing something right. We truly care about both our clients and our employees, and as a result, we don’t see a lot of turnover with either. In fact, our average tenure for our employees is around 13 years. Clients appreciate seeing familiar faces mixed in with the new ones as we continue to grow.
Still have questions about CC Pace?
Reach out to us today to learn more about CC Pace and what we can do for your business!
To find out more about our people and our culture, get social with us on LinkedIn and Facebook!
As any successful leader will tell you, it is the people in your company who ultimately determine the success or failure of your business. At CC Pace, we know that our people are our most important asset, so employee recognition is a big part of our corporate culture. It is important to us that our employees are recognized throughout the year, not only for milestone anniversaries, but for other things like specific contributions to our company big or small. Those recognitions can take on different forms: sometimes it’s a public “shout out” during our quarterly meetings, other times team leaders may present spot bonuses, and yet other times co-workers and leadership team will express their appreciation at a personal level. But, we do have one major event each year to thank all our employees at the same time, and that is our annual party.
Who doesn’t love a great party, right? Our annual get together allows our entire team to celebrate our accomplishments together. It’s also a great opportunity for those working remotely or at client sites to reconnect with their colleagues, mingle and have some fun. This year’s event took place at Ruth’s Chris where the food was amazing, the spirits were exceptional, and the atmosphere was festive!
Prior to our annual event, we held our corporate staff meeting where we had an opportunity to recognize and celebrate Erika Palomino and Steve Chojna’s 15 Year Anniversaries with CC Pace – wow! Erika is our Lead Contracts Specialist. She handles all our contracts, vendor negotiations, contract reviews, and all other required contractual documentation. She also helps support and manage our GSA contract, which is no small undertaking. But it’s not all business with Erika, as she has also added tremendous value and fun to our company culture as a member of People Engagement Committee (PEC). Her creativity and humor have led to some very entertaining and memorable events. A big thank you to you Erika!
Steve is a Senior Consultant in our Financial Services practice. During his time with us he has worked with a wide variety of mortgage clients on various implementations, spent some time with Agile development writing user stories and has spread his wings now to documenting the business processes for managing the acquisition of genomic and phenomic research data. Steve does all of this with a good-natured spirit of collaboration and an infectious smile! Really, this guy is always in a good mood! Cheers to you Steve!
Our President, Mike Gordon, presented Erika and Steve each with a service award and the traditional CC Pace gag gift – though everyone was super jealous of Erika’s (we can’t say what it was, but it was a bottle of something that rhymes with shekila).
Here are some photos we captured from our fun festivities – enjoy!
CC Pace recently completed an interesting project for a mortgage lender who had just done an acquisition. The project questioned a fundamental assumption of loan pricing and whether the existing approach was compliant or not. One entity had “branch” pricing (as do many lenders), where the price quoted to the borrower is based on the branch rate sheet of the loan officer that the borrower works with. The second entity, however, had pricing based on where the property was located (also a common practice). Compliance recognized that these two different methodologies could result in disparate pricing to the consumer, potentially leading to fair lending violations.
Having been in the industry for a long time, the notation of pricing based on the loan officer’s rate sheet didn’t seem unusual to me. We have implemented this model many times, going back to the 1980’s. It was so ingrained that I had never really thought about it. But this project challenged my assumptions and changed my way of thinking—for the better.
In retrospect, under the “right” (wrong?) use cases the lender could have faced fair lending penalties even before the acquisition. For example, if a borrower was looking for loan for a second home and had gotten quotes from both their local branch and from the branch in the property’s geography, those quotes could easily have been different.
Our client’s Compliance group recommended moving everyone to the geographic model – pricing based on where the property is located, not based on where the loan officer is located. And pricing should include “junk” fees, which were determined by the Sales organization, whereas Secondary determined rates & points. CC Pace’s role was to lead this transition, a major shift for a lender who hadn’t re-thought their pricing in many years.
Redesigning processes that were deeply ingrained in the organization and systems made for an interesting project. How do you define the geographies? Zip code level is too small to be compliant; MSA is better. But using every MSA in your footprint may be too many geographies to maintain. How do you align the “junk” fees with the geography and with the organization? Who actually sets the branch rates? What updates do you need to make to your rate sheet? What new training do you need to do?
Much of the elapsed time for the project was spent in the conceptual design and getting it approved by the stakeholders and Compliance. However, the bulk of the man-hours were spent updating and testing the pricing engine and loan origination system for both pricing and fees, and then testing the systems across all the different use cases (retail, call center, digital). There was also a need for some organizational realignment of responsibilities. Surprisingly, however, the re-training of loan officers turned out not to be very difficult.
I came away from this experience realizing that this was an important project that many lenders may need to consider, even if they are not doing an acquisition.
How does your organization price loans?
What are your New Year’s resolutions for 2019? The most common resolutions people make on a personal level are to exercise more, lose weight, get organized and save money. The start of a new year is also the ideal time of year to define and set your business goals as well.
Why set business goals? Business goals can determine the direction of your career, motivate you to keep moving forward and measure your success. Setting business goals may be something you decide to do individually as personal career goals, with others as a team, or even on a company level. First and foremost, your personal business goals should focus on moving you forward professionally and expanding your skills development.
Examples of personal business goals may include:
To grow your network
Learn a new skill
Become a thought leader in your field
Set aside time on your calendar each week to manage your emails
Research business solutions
Become a better listener
Write down your goals and specific action steps so you can see them and keep track of your success. Don’t rush and try to tackle them all at once. Take your time and focus on only one or two at a time. At the end of the year, take a moment to review all that you have accomplished – you will be surprised by what you can do once you set a goal.
At CC Pace, we have helped over 35,000 people reach their professional goals through our training offerings. We have a variety of resources available to help further your learning on our website including: articles, white papers and blogs posts; as well as our training offerings, to help you further your knowledge and skills.
Happy New Year – Here’s to making 2019 your most successful year yet!
I recently came across a blog written by a former developer at ORACLE.
The author highlighted the trials and tribulations of maintaining and modifying the codebase of Oracle (version 12) database. This version, by the way, is not some legacy piece of software, but is the current major version that is running all over the world. According to the author, the codebase is close to 25 million lines of C code and described as “unimaginable horror”. It is riddled with thousands of flags, multitudes of macros and extremely complex routines that were added by generations of developers trying to meet various deadlines. According to the author, this is a common experience for an Oracle developer at the company (their words, not mine):
Start working on a new bug.
Spend two weeks trying to understand the 20 different flags that interact in mysterious ways to cause this bug.
Add one more flag to handle the new special scenario. Add a few more lines of code that checks this flag and works around the problematic situation and avoids the bug.
Submit the changes to a test farm consisting of about 100 to 200 servers that would compile the code, build a new Oracle DB, and run the millions of tests in a distributed fashion.
Go home. Come the next day and work on something else. The tests can take 20 hours to 30 hours to complete.
Go home. Come the next day and check your farm test results. On a good day, there would be about 100 failing tests. On a bad day, there would be about 1000 failing tests. Pick some of these tests randomly and try to understand what went wrong with your assumptions. Maybe there are some 10 more flags to consider to truly understand the nature of the bug.
Add a few more flags in an attempt to fix the issue. Submit the changes again for testing. Wait another 20 to 30 hours.
Rinse and repeat for another two weeks until you get the mysterious incantation of the combination of flags right.
Finally one fine day you would succeed with 0 tests failing.
Add a hundred more tests for your new change to ensure that the next developer who has the misfortune of touching this new piece of code never ends up breaking your fix.
Submit the work for one final round of testing. Then submit it for review. The review itself may take another 2 weeks to 2 months. So now move on to the next bug to work on.
After 2 weeks to 2 months, when everything is complete, the code would be finally merged into the main branch.
Millions of tests
As I read this post, I started getting a little nervous, being a software developer and currently interacting with an Oracle 12 database. Quickly it became clear that millions of tests were acting as a true line of defense against the release of disastrous software. It was interesting to read that the author was diligent in adding tests not just because it was his job, but out of concern for ensuring that future developers will not break the bug fix being added. There are probably many ways of streamlining the development lifecycle described by the author, and maybe it is a topic for another blog, but it seems that having hundreds or thousands of failed tests is infinitely better than the alternative.
The black box
Product owners and business stakeholders are not the only people in an organization that may view their codebase as a black box. Developers may as well. As the number of lines of code grows over time, no institutional knowledge can cover the various nuances and complexities that various features introduce. When new developers are added to a project, the value of having automated tests becomes more pronounced. Organizations should strive to remove the perception of the code being a “black box” as much as possible. Failure to do so will result in loss of confidence in quality and viability of the products and features being developed, not to mention placing unnecessary burden on test teams.
Legacy Systems
I have heard horror stories from colleagues and friends about maintaining “legacy” systems. One question that comes to mind is if the system is being modified, is it really a legacy system, or is it just an old system that is still updated? In my experience, if a bug fix or a new feature is being added to an older system, the cost of not automating the corresponding tests most often results in some other seemingly unrelated bug being introduced. Sometimes it can be very difficult to automate tests especially in old systems. There may not be any available testing frameworks that could be easily plugged in. In such cases I would advocate for writing your own testing framework. It may not be as sophisticated as some of the commercial or open source packages, but it will help immensely. Testing automation of older systems can also ensure a smooth retirement of obsolete features that keep the codebase bloated and more complex that it needs to be.
Flaky Tests
In my experience, having more automated tests is better than having less. Over time, tests may be become redundant as they are being added. This is not the worst problem to have and can generally be managed as technical debt. What is worse, is presence of flaky tests. These are tests that change from passing to failing from day to day with no clear explanation. These result in significant time sink and loss of confidence in the product being developed. Getting rid of such tests should be the top priority. Ideally, they should be rewritten and made more robust, but in some cases, they may be completely removed as they do not reliably prove that the software is working as it should.
Conclusion
Test automation is not new, but it still appears to be lacking in many systems. Organizations should embrace the cost of test automation as part of the cost of developing new features and modifying existing ones. Doing so will help build confidence in ensuring quality for product owners as well as developers.
Happy testing!
Last week we had our quarterly staff meeting and the room was full of company spirit as our employees were all sporting CC Pace apparel. We also had a new twist when it came to discussing company business as some of our consulting teams made project videos to highlight their work – it was an entertaining way to learn about their current assignments and the clients they support. Once we got all the serious business out of the way, we had some fun as we recognized 3 employees who had reached milestone anniversaries.
First, we have Deepti Agarwal, Senior Technical Recruiter who is celebrating 5 years as a member of our recruiting team. Deepti was recognized for her exceptional record of having a 95% retention rate for her placements. Her colleagues are quick to point out that her attention to detail gives her the ability to find the perfect match for both the candidate and the client. Deepti received the traditional gag gift presented by President, Mike Gordon and a service award. Way to go Deepti!
Second, we celebrated Clay Everhart our Facilities Manager for 20 years of service. Clay has a big fan club here at CC Pace as he is always the first to lend a helping hand, volunteer or assist with a project (and of course make a joke). Most importantly, he does everything with a smile and always provides a funny quote of the day for our staff to enjoy! Mike presented Clay with a service award and, of course, a gag gift! But, the highlight of honoring Clay came next. For those who are not familiar with Clay, he also plays the guitar and is a songwriter and he performs his original pieces for everyone at CC Pace when there is a milestone anniversary or retirement. While they are often hilarious, they can also be very sweet and touching. To celebrate his anniversary, the entire CC Pace team wrote and performed a song for him to the tune of Barry Manilow’s I Write the Songs! A classic moment for sure and one we will all remember for a long time. Thanks Clay for everything you do and all the laughs you bring to CC Pace!
Third, we had the honor to celebrate the 40th anniversary of Mike Gordon, CC Pace President. Mike started for a company named R. Shriver Associates in the late 70’s. In 1980, Mike and one other person purchased the branch and that was the beginnings of CC Pace. For 40 years Mike has led CC Pace with the highest integrity and ethics and through his strategic vision, he has built the company where it is today – a known leader in our market place. Mike was honored with a service award presented by Dawne Ward, COO. Dawne also had the special privilege of giving Mike a taste of his own medicine and presenting him with some gag gifts, and we have to admit he looked a little nervous when that part came around! The team also presented him with a golf outing to enjoy. Cheers to you Mike and thank you for your outstanding leadership of CC Pace!
The staff meeting also marked the last day of our Toys for Tots drive! Toys for Tots was started in 1947 and has distributed over 548 million toys since it began. We were able to fill two very large boxes with toys for our local community. The donations we received included something for everyone with baby dolls, cars, board games, craft sets, Legos and much more! Who doesn’t love the chance to make a child happy?!
A big shout out to all our employees for participating in this event!
This year marked the 32nd Annual Gala and Silent Auction held by SOME (So Other Might Eat). SOME is an interfaith, community-based organization led by Father John Adams, to help the homeless and poor of our nation’s capital. They provide basic needs of food, clothing, and health care to those in need on a daily basis, as well as job training, addiction treatment, and temporary housing to assist in long-term needs geared towards eliminating their current homeless situation.
The Gala and Silent Auction funds for the last 32 years have helped to ensure that SOME is able to sustain their services for another year. Suzanne Clark, a member of our Corporate Advisory Board, was this year’s Silent Auction Chair. Suzanne has been a part of the Silent Auction committee for the past 15 years and her support and leadership has been critical to SOME.
The Silent Auction consists solely of generous donations by businesses and individuals. Auction items this year did not disappoint the nearly 700 guests who attended the Gala. So many wonderful items to bid on were available, with highlights including: Ambassador-hosted embassy dinners, tickets to top concerts, grand getaways, fine wines, family activities and spa packages. CC Pace President and SOME Corporate Advisory Board Member, Mike Gordon and his wife Tracy donated a New England Clambake for 20 guests that brought in a winning bid of $1,100 to help the homeless. The total amount raised from this year’s Gala and Silent Auction was approximately $1.1M.
Each year, SOME presents the Father Horace McKenna Humanitarian of the Year Award to individuals who have performed outstanding work to benefit the poor and homeless in Washington DC. This year Allison and Matthew Shay were the honorees and were highlighted for their volunteerism as event chairs and committee members, their in-kind donations, their fundraising and their own generous financial contributions.
Each year CC Pace is proud to be a supporter of SOME and the services they provide to those less fortunate in our community. Visit SOME.org to learn more about this organization and how you can help.
Although Charles Darwin adopted the term “Survival of the Fittest” from Herbert Spencer to describe his theory of evolution, it is easy to misunderstand if you don’t have context for what “fittest” means. Darwin’s theory of natural selection showed how, in the long run, organisms that could adapt to changes in their environment out-survived organisms that were highly efficient in the current environment but rigid, and slow to adapt.
How is this relevant to loan origination? Few industries exist in an environment that changes as frequently as that of mortgage banking.
Many lenders with what they believe to be a highly-efficient process seek to memorialize that process in their loan origination systems (LOS) through customization – only to find that when they need to upgrade their systems, doing so is time-consuming and difficult.
Too frequently lenders look at the newest release from their LOS vendor and think “how do I get there from here?” How should lenders be thinking about bringing their customizations forward into their new release?
“This porridge is too hot. This Porridge is too cold.” – Goldilocks
Previously, many lenders defined the ideal LOS as one that was customized to their way of doing business – what was the most efficient at the time. However, the combination of FinTech, new POS technology, the new ULRA, and the constant pace of change are forcing many lenders to take major system upgrades, and to re-think their LOS customization strategy.
Even with some (temporary) regulatory relief, the overall pace of change is speeding up. Many LOS and POS vendors now expect to make a significant release each year, and to continue on that pace, with the requirement that lenders adopt the new releases faster. But that is OK, because the business case for their adoption is growing stronger. Being able to take new releases quickly and easily is the new efficiency.
The best strategy is to make your organization (process, technology and people) as adaptable as possible. How does a lender do that? Although here at CC Pace we help lenders with all three aspects, for the sake of this blog, we will focus on just one: the technology, in this case the LOS.
Typically, the hardest part of taking an upgrade is making sure the customizations survive the transition and associated regression testing.
Therefore, before doing an upgrade, organizations should look at their customizations and determine “given what I know now, and how the package operates out of the box in the latest release, would I make this customization again?”
“Ahhh, this porridge is just right” – Goldilocks
Some Valid Reasons for Customization
Internal interfaces
Something particular to your business that is not handled in the package, e.g., a custom funding module
Support for a different regulatory interpretation (But work hard to see if the vendor’s interpretation isn’t actually acceptable.)
Some Invalid Reasons for Customization
Low-level users on the project demand a change without regard for the long-term business case (that includes the cost of making and then maintaining the customization). Sometimes even if the change is better, it might not be worth it.
Exception processing – a mature system (which is typically the type being replaced) will likely have grown to handle exceptions. However, I have seen too many cases where people forget that they are processing exceptions – and let “the rules” pass them by. Focus on getting the straight through process to work.
There is a continuum between a strict “No Customization” policy at one end, and the previous “We bought this system to be able to customize it, let’s do it” at the other.
Goldilocks
An organization should strive for “Goldilocks,” that sweet spot where you implement important customizations, but the rational for the change is made by management, after detailed discussions with the vendor, and performed in a way as to have lower maintenance costs.
If you are one of these lenders with highly customized systems, what is your upgrade strategy?
Now that you have hired millennials, this last blog in our millennials series discusses integrating them to become part of your team, and making changes to your organization to fit their professional needs. As with any new employee, it takes time for that person to become acclimated to your organization.
This article, 2018 Millennials at Work Report, touches on managing this generation, millennials in leadership and long-term change. Making small changes across the board to create a more relaxed work environment seems to be a key starting point. Even employees outside of this generation will welcome change as they too seek more flexible schedules, cutting edge technology, professional development and management feedback.
If leaders are willing to take the time to invest in this generation of workers, it will surely make a difference to not only their teams, but their business.
Congratulations to Dawne Ward, our Chief Operating Officer (COO) who is celebrating her 20 Year Anniversary with CC Pace! Prior to CC Pace, Dawne worked at Citibank in their mortgage department for many years. She started with us as a consultant at Freddie Mac before taking over as our Account Manager. Her relationship with Freddie Mac helped to orchestrate the partnership we still have with them to this day.
As COO, Dawne is responsible in overseeing marketing, contracting, HR, Payroll, 401K Administration and so much more. Mike Gordon, President of CC Pace, stated, “Dawne works extremely hard, she always has the company’s best interest at the forefront and all of us have been the beneficiaries.”
At our Quarterly Staff Meeting, Dawne was not only honored with a Service Award and the traditional CC Pace gag gift from Mike, but also a very special performance by Clay with a humorous song written just for her!
We recognize that 20 years is a huge commitment to a company, so thank you, Dawne, for all you do for CC Pace!
CC Pace is ready for AgileDC! We are looking forward to hearing some great speakers and meeting with other Agile practitioners in the DC area. As a sponsor this year, we’re excited to be a part of what is always a great local event for the Agile community. Don’t forget to stop by our booth to meet our team and enter our drawing for your chance to win a $500 Amazon Gift Card!
See you at AgileDC!
As digitization of the mortgage process (finally) gains steam, lenders need to start looking towards the future when everyone is digital. What will it mean for the industry?
An aspect of the digital process that is often overlooked is that an increase in digitization is equal to a decrease in interpersonal connectivity. Insofar as that interpersonal connectivity is what binds a borrower to a loan office or lender, what will provide that binding compound in the future? How will you make your brand stand out? What will make a borrower come to you versus the next lender in their google search?
Quicken took a very forward thinking, positive step when they introduced Rocket Mortgage to a huge audience via their super bowl ads. Many people now equate a digital or online experience with “Rocket Mortgage”, similar to how a copier is called a Xerox machine or a tissue a Kleenex. Only time will tell if that sticks, but it is definitely a presence in the market today that everyone has felt.
The commoditization and loss of a personal interchange is not new. People used to visit a specific gas station because they trusted a brand or liked “Jimmy” and thought he was a nice guy that always did such a great job cleaning your windows (remember when that happened!?!). Consumers developed a personal relationship that drove what gas station they visited most frequently. Today, almost all gas stations require little to no interaction with a person, with their credit card machines at the self-serve pumps (except in states like NJ, but that’s another story). People most often simply buy based on price and convenience. If you asked people what brand gas they bought most recently, many would not know the answer. Today, the competitive landscape for gas stations is therefore very much price based. The competition is made more intense with the sharing of data via apps like GasBuddy, so people can easily compare prices in their area and pick their vendor for the next fill-up.
With digitization and the increasing popularity and use of Day 1 Certainty and Loan Advisor Suite functionality accelerating the process, getting a mortgage from Lender A or Lender B will not differ much at all for most borrowers. They will select based on price and convenience. Depending on the results of their google search, it may end up being more of the latter than the former. Standing out amidst commoditization will then be critical to survival. How will you be found by a potential borrower? Why should they apply with you versus another lender?
CC Pace employees held their second food packing event to support the efforts of Food for Others Power Pack Program. The program was designed to ensure that elementary school kids in need of food in Northern Virginia have enough to eat over the weekend. In Fairfax County alone, more than 60,000 people are considered food insecure. Each Power Pack gives the children healthy balanced meals, and helps those families who need it most.
All the supplies needed were purchase by CC Pace, and we had over a dozen employees participate in this community outreach event. Our team of volunteers had a great time, working together to assemble 48 packs for a total of 288 meals! All the packs were personally delivered by our volunteers and will be distributed by Food for Others.
At heart, I’m still a developer. Titles or positions aside, what I enjoy most is solving problems and writing good code to implement the solutions. And so, when I work on strategic technology engagements, I often empathize with the developer teams, and can clearly see their points of view.
One issue I often see on such engagements is that the developer teams find little or no value in the Agile retrospective meetings. I hear expressions like, “waste of time,” or, “lots of psychobabble.” I understand where developers are coming from when they express these sentiments, but I disagree with them. If done well (emphasis on well), retrospectives are absolutely essential and make developers’ lives much better. When developers are so cynical about retrospectives, I know that retrospectives are not being conducted very well.
Let’s take a look at some of the “anti-patterns” I’ve seen.
Pro forma retrospectives
In a pro forma retrospective, everybody takes turns to say what they like and what they think can be improved. So far, so good. But nobody is encouraged to develop their thoughts or to expound. So week after week, the retrospective’s answers are, “Everyone is doing a great job, working hard,” and, “Nothing is really wrong.” At that point, the meeting is no longer a retrospective, it’s just a ceremony.
The coach or the scrum master should encourage everyone to speak their minds. Developers coming from a waterfall background, or from a “command and control” background, may not be comfortable expressing their doubts and reservations. Make sure they’re encouraged to do so.
Using attendees as lab rats
Some coaches I worked with thought that projects were an ideal way to test out new approaches to retrospectives that they had dreamed up. One involved putting stickies on team members’ foreheads and trying to guess something… I don’t even remember the details, the whole thing was so silly. Another thought that putting things in verse was a good idea. I have no idea where in left field these notions come from, but all they succeeded in doing was making the team members feel totally patronized.
Stick with tried and true methods: ask for things that are going well and should be reinforced, then things that need improvement, then action items for reinforcement and improvement. If you want to experiment, that’s fine, but make it clear it’s an experiment and ask for feedback on the experiment itself.
Not following up on action items
Some retrospectives do everything right in the meeting, but nobody acts on the action items. Now it’s just a gab session, not a useful discussion. Make sure the Scrum Master acts outside the meeting to reinforce the good and improve the bad. Then discuss the actions taken at the next retrospective, so that everyone sees something is being done. If there’s time, revisit the improvement areas from the last meeting and ask if things have improved.
Without actual followup, developers will chalk up another “I’ve seen it all before” score, and will see the meetings as wastes of time.
Putting people on the spot
Retrospectives should be about making things better, not about forcing members to be defensive. I’ve seen them run as blame sessions, where “who’s to blame for this?” is the aim. Don’t be that person. The team should be accountable, yes, but trying to affix blame on individuals or groups isn’t productive. Instead, ask everyone for suggested action items to improve the situation, and make sure everyone signs on to the action items.
As developers, we’re trained to expect the worst and to see risk everywhere. Sometimes, it makes us cynical and resistant to faddish concepts. Retrospectives are not that. They’re useful forums to express frustrations in a civil and productive way so that frustrations don’t build up and lead to disruptive behavior in other settings. If conducted well and if effective action is taken, they really do lead to tangible improvements that make everyone’s jobs much easier, including developers.
If you notice that your developer team thinks retrospectives are worthless, glance at this checklist:
Don’t patronize the developers or ask them to defend themselves
Show you’re listening by actually effecting requested changes
Value the outcome of the meetings over the process of the meetings
CC Pace would like to introduce you to Donna Kenney, our new Controller who recently joined our Accounting team. She started her accounting career working for public accounting firms, and prior to joining CC Pace, she worked at Seneca Corporation for 20 years as a Controller. In her role, Donna is responsible for leading our Accounting operations and financial analysis/reporting functions. She is extremely customer-focused and has already hit the ground running.
What made you want to work for CC Pace? The Controller position described in the online job posting sounded like the mix I was looking for; it involved all financial aspects, plus a good mix of hands-on and oversight activities. It was a smaller company and a tech company, which is the industry I’ve enjoyed working in since leaving public accounting. I checked out the CC Pace website and learned a little more about the company, and I really felt that this was the place I had been waiting for to make my next move. One reason was the mix of business lines and client types. However, the huge draw for me was the employee friendly feel that I got initially from the website, and then it was reinforced again during the interview process. Having worked at a company for almost 20 years where a number of employees had also been there 10+ years, the personality and corporate culture of my next company was very important to me. A company that could boast a similar retention rate was a big plus when deciding to submit my resume, and then ultimately saying yes to an offer.
In terms of moving to a new company, what has been your biggest challenge? Getting used to all the different processes and details. Luckily, I have a great staff that has helped with the transition, and everyone else here at CC Pace has been very supportive. It has actually been relatively smooth so far. (Hopefully I didn’t jinx anything just now!)
What is your initial impression of the culture at CC Pace? As I mentioned, the atmosphere has been friendly and supportive, a true team working toward the same goals, where professionalism and respect are just a natural part of the package.
What 3 words best describe CC Pace? Probably not what you’re looking for, but what comes to my mind is simply “the right fit!”
If you could meet anyone, living or dead, who would you meet? Why? That’s a hard question to answer, but I’ll say my Aunt Ann. I am actually named after her (Ann was actually her middle name though she went by it, as it is mine). She passed away a few years before I was born, but growing up I was often told how much I resembled her. I think it would be interesting to meet her for both of those reasons.
What was the last book you read?Awaken the Darkness by Dianne Duvall
What was the first job you had where you earned a real paycheck? At GC Murphy’s a 5&10. My mom worked there for many years, when I was young we would stop in the store and I always wanted to “help!” Particularly, using the pricing gun to put the price stickers on new merchandise. I will admit actually getting paid and having to use the pricing gun took some of the pleasure out of it, versus when I wasn’t actually supposed to be using it and was just “helping” mom.
Do you have a favorite quote? My dad always said, and I always try to keep in mind: Everything happens for a reason and in the end works out for the best whether we understand it (or the hows/whys of it) or not.
Whether delivered by a rocket or obtained at a depot, the reality is that the digital mortgage has finally arrived. Regardless how different organizations may define digital mortgage, the fact remains that mobile applications, eSignings, and eNotes are very real, with more lenders steadily getting on board. This then begs the question, “Alexa, what’s next in lending?”
Today the answer appears to be blockchain, artificial intelligence (AI), and robotic process automation (RPA). This article takes a look at why these technologies may be the next big deal.
To begin, let’s look at blockchain, the secure distributed ledger system behind cryptocurrencies such as Bitcoin. Tim Williams, Managing Director, Institutional Equity Sales, at GMP Securities, who specializes in blockchain, told me in no uncertain terms, “Blockchain will singlehandedly completely disrupt the infrastructure of all sales transactions worldwide.” Tim went on to explain how blockchain will become a required component within the fabric of all software support systems to complete a sales transaction, especially in the banking and mortgage banking sectors. That said, Tim then issued a stern warning to those firms operating on legacy systems, “They should be most concerned since you can’t just thread blockchain into an existing architecture or infrastructure. It’s not only a preposterous experiment, but impossible.” Tim estimates that every organization is going to have to strip out their existing legacy system and replace it with a blockchain-based platform. This is a significant consideration that lenders and mortgage bankers will have to seriously ponder, especially when considering all the benefits that blockchain promises to deliver.
Blockchain is already making significant strides to help reshape the housing industry in other parts of the world, helping organizations, cities, and even countries achieve real cost savings, security, and efficiency. Ukraine’s government recently passed new laws requiring blockchain, as it is believed to be the catalyst to help drive up their real estate values, which have fallen nearly 70%. Sweden, one of the leaders in blockchain adoption, is currently in the third phase of its move to blockchain-enabled land title registry. The Swedish government believes blockchain could save their taxpayers over $100 million a year by being able to do faster loan transactions, significantly reduce paperwork, and dramatically reduce fraud. Following Sweden’s lead, the United Kingdom is completely re-designing their land registry system using blockchain as the foundation. Maria Harris, Director of Intermediary Lending, at Atom Bank in the UK, says, “blockchain allows us to get to a point where the customer might be looking at an online estate agent and clicking through to get that data as part of looking at a house and get approved, before they even engage with a lender.” Based on these success stories, it appears the US mortgage markets have some catching up to do.
Next, let’s look at artificial intelligence, or AI, also referred to as intelligent machines or machine learning. While many may think that AI is the realm of IBM’s Watson platform or nifty devices from Amazon being used in the home for simple tasks such as building shopping lists or turning on lights, a few lenders are starting to leverage AI’s capabilities to help reduce support costs, increase efficiencies, and improve the customer experience. Scott Slifer, the CEO at Sutherland Mortgage Group in Raleigh, NC highlights how they do social media monitoring using AI to scour Twitter, Instagram, and Facebook for any negative commentary that pops up so that they can address issues immediately when they are uncovered. At Atom Bank in the UK, Amazon’s Alexa platform is helping mortgage brokers by letting them access case tracking and the to-do-list on any given transaction. Alexa will communicate what cases are outstanding, what documents they’re waiting on, and who is doing a valuation on what day. One of the fastest growing banks in Europe, Atom Bank implemented a combination of AI tools, including chatbots and an avatar, to collectively reduce inbound phone calls by 92%. Atom claims the cost savings are adding up quickly, particularly when servicing over a million loans.
Lastly, lenders will need to adopt more advanced Robotic Process Automation (RPA), something that often goes hand in glove with AI. RPA is the use of software to handle high-volume, repeatable tasks that previously required humans to perform. A survey of 1,500 banks and lenders conducted by Capgemini in July 2018 found that while 40% have successfully adopted RPA using the basic RPA tools, such as imaging and programming rules to automate tasks, only 4% have gone on to use the more advanced functionality of RPA. It is estimated the machine learning component of RPA is where the real operational, long-term, cost savings will be achieved. Sarah Green, director of business development at Sutherland Mortgage Services UK, estimates that Sutherland’s 205 bots currently handle over 120,000 transactions each month, driving nearly a million dollars in monthly operating cost savings.
In another example, OCBC Bank in Singapore has been experimenting with RPA since 2015, assisting the consumer secured lending team with home loan restructuring and slashing processing time by 97%. Prior to RPA, these tasks involved an employee executing 199 process steps while toggling across five systems and 27 screens for one loan application, a process that took more than 45 minutes to complete. Now, with a well-programmed bot in place, it takes just one minute. Another bot at OCBC is assigned to the finance team to help with sales performance reporting – a task that took 120 minutes when handled by one bank employee. The RPA bot does the job in just 12 minutes. When considering bot development, Cheryl DeRoche Johnson, managing director of innovative solutions at MUFG Union Bank indicated, “you have to consider your robots as another set of staff. You wouldn’t have staff do a job without having process and procedures in place.” As a result, you’ll have to program the appropriate rules, process flows, policies, and procedures to successfully train the bots. While RPA’s machine learning capabilities are still in the very early stages, it’s apparent the savings are already adding up.
When considering the sophistication of these tools, lenders need to recognize them as being more challenging than ever to develop, integrate, and implement, but well worth the effort. So how do we get there from here? While the answer isn’t necessarily crystal clear, or the path altogether easy, one thing is for certain: the next wave of change is just starting and we all need to be involved. CC Pace is here to help you successfully transition from the current state to the future state. As we like to say: “You see problems; we see solutions.”
We came across in interesting article on Tips for Interviewing Millennials (And What They Really Want from a Job). It discusses how, in the workforce today, there are 5 different generations of workers. How does an employer position themselves to be attractive to each of these generations?
The first step would be understanding what each generation is looking for in an employer and seeing how that fits within your organization. Millennials have quickly become the largest growing pool of candidates and interviewing them may be a bit different than previous generations.
The top items they want to hear about are equality, flexibility and growth. This article will give you some key questions to ask to ensure both you and the candidate are on the same page to create a perfect union.
Introduction
In the last post, we looked at pattern matching and data structures in Elixir. In this post, we’re going to look particularly at Elixir processes and how they affect handling errors and state.
Supervisors & Error Handling
Supervisors, or rather supervision trees as controlled by supervisors, are another differentiating feature of Elixir. Processes in Elixir are supposed to be much lighter weight than threads in other languages,[1] and you’re encouraged to create separate processes for many different purposes. These processes can be organized into supervision trees that control what happens when a process within the tree terminates unexpectedly. There are a lot of options for what happens in different cases, so I’ll refer you to the documentation to learn about them and just focus on my experiences with them. Elixir has a philosophy of “failing fast” and letting a supervision tree handle restarting the failing process automatically. I tried to follow this philosophy to start with, but I’ve been finding that I’m less enamoured with this feature than I thought I would be. My initial impression was that this philosophy would free me of the burden of thinking about error handling, but that turned out not to be the case. If nothing else, you have to understand the supervision tree structure and how that will affect the state you’re storing (yes, Elixir does actually have state, more below) because restarting a process resets its state. I had one case where I accidentally brought a server down because I just let a supervisor restart a failed process. The process dutifully started up again, hit the same error and failed again, over and over again. In surprisingly short order, this caused the log file to take up all the available disk space and took down the server entirely. Granted this could happen if I had explicit error handling, too, but at least there I’d have to think about it consciously and I’m more likely to be aware of the possibilities. You also have to be aware of how any child processes you created, either knowingly or unknowingly through libraries, are going to behave and add some extra code to your processes if you want to prevent the children bringing your process down with them. So, I’m finding supervisors a mixed blessing at best. They do offer some convenience, but they don’t really allow you to do anything that couldn’t be done in other languages with careful error handling. By hiding a lot of the necessity for that error handling, though, I feel like it discourages me from thinking about what might happen and how I would want to react to those events as much as I should. As a final note tangentially related to supervisors, I also find that the heavy use of processes and Elixir’s inlining of code can make stack traces less useful than one might like.
All that being said, supervisors are very valuable in Elixir because, at least to my thinking, the error handling systems are a mess. You can have “errors,” which are “raised” and may be handled in a “rescue” clause. You have “throws,” which appear not not have any other name and are “thrown” and may be handled in a “catch” clause and you have “exits,” which can also be handled in a “catch” clause or trapped and converted to a message and sent to the process outside of the current flow of control. I feel like the separation of errors and throws is a distinction without a difference. In theory, throws should be used if you intend to control the flow of execution and errors should be used for “unexpected and/or exceptional situations,” but the idea of what’s “unexpected and/or exceptional” can vary a lot between people, so there’s been a few times when third-party libraries I’ve been using raise an error in a situation that I think should have been perfectly expectable and should have been handled by returning a result code instead of raising an error. (To be fair, I haven’t come across any code using throws. The habit seems to be handle things with with statements, instead.) There is a recommendation that one should have two versions of a method, one that returns a result code and the other, with the same name suffixed with a bang (File.read vs. File.read!, for example) and raises an error, but library authors don’t follow this convention religiously for themselves, and sometimes you’ll find a function that’s supposed to return no matter what calling a function in yet another library that does raise an error, so you can’t really rely on it.
I haven’t seen any code explicitly using an exit statement or any flow control trying to catch exits, but I have found that converting the unintentional errors that sometime happen into messages allows me to avoid other processes taking down my processes, thus allowing me to maintain the state of my process rather than having it start from its initial state again. That’s something I appreciate, but I still find it less communicative when reading code as the conversion is handled by setting a flag on the process, and that flag persists until explicitly turned off, so I find it harder to pinpoint where in my code I was calling the thing that actually failed.
All-in-all, I think that three forms of error handling are too many and that explicit error handling is easier to understand and forces one into thinking about it more. (I happen to believe that the extra thinking is worthwhile, but others may disagree.) That being said, adding supervision trees to other languages might be a nice touch.
State
Given that the hallmark of functional programming languages is being stateless, it may seem odd to conclude with a discussion of state, but the world is actually a stateful place and Elixir provides ways to maintain state that are worth discussing.
At one level, Elixir is truly stateless in that it’s not possible to modify the value of a variable. Instead, you create a new value that’s a function of the old value. For example, to remove an element from a list, you’d have to write something like:
my_list = List.delete_at(my_list, 3)
It’s not just that the List.delete_at function happens to create a new list with one fewer element, there’s no facility in the language for modifying the original value. Elixir, however, does let you associate a variable with a process, and this effectively becomes the state of the process. There are several different forms that these processes can take, but the one that I’ve used (and seen most used) are GenServers. The example in the linked document is quite extensive, and I refer you to that for details, but essentially there are two things to understand for the purposes of my discussion. On the client side, just like in an OOP, you don’t need to know anything about the state associated with a process, so, continuing with Stack example from the documentation, a client would add an element to a stack by calling something like:
(Note that process_identifier can be either a system generated identifier or a name that you give it when creating the process. I’ll explain why that’s important in a little while.) On the server side, you need code something like:
def handle_call({:push, value}, from, state) do
…
{:reply, :ok, new_state}
end
Here, the tuple {:push, value} matches the second parameter of the client’s invocation. The from parameter is the process identifier for the client, and state is the state associated with the server process. The return from the server function must be a tuple, the first value of which is a command to the infrastructure code. In the case of the :reply command, the second value of the tuple is what will be returned to the client, and the final value in the tuple is the state that should be associated with the process going forward. Within a process, only one GenServer call back (handle_call, handle_cast, handle_info, see the documentation for details) can be running at a time. Strictly in terms of the deliberate state associated with the process, this structure makes concurrent programming quite safe because you don’t need to worry about concurrent modification of the state. Honestly, you’d achieve the same effect in Java, for example, by marking every public method of a class as synchronized. It works, and it does simplify matters, but it might be overkill, too. On the other hand, when I’m working with concurrency in OOP languages, I tend towards patterns like Producer/Consumer relationships, which I feel are just as safe and offer me more flexibility.
There is a dark side to Elixir’s use of processes to maintain state, too: Beyond the explicit state discussed above, I’ve run into two forms of implicit state that have tripped me up from time to time. Not because they’re unreasonable in-and-of themselves, but because they are hidden and as I become more aware of them, I realize that they do need thinking about. The first form of implicit state is the message queue that’s used to communicate with each process. When a client makes a call like GenServer.call(pid, {:push, “something”}), the system actually puts the {:push, “something”} message onto the message queue for the given pid and that message waits in line until it gets to the front of the queue and then gets executed by a corresponding handle_call function. The first time this tripped me up was when I was using a third-party library to talk to a device via a TCP socket. I used this library for a while without any issues, but then there was one case where it would start returning the data from one device when I was asking for data from another device. As I looked at the code, both the library code and mine, I realized that my call was timing out (anytime you use GenServer.call, there’s a timeout involved; I was using the default of 5 seconds and it was that timeout being triggered instead of a TCP timeout), but the device was still returning its data somewhat after that. The timing was such that the code doing the low-level TCP communications put the response data into the higher-level library’s message queue before my code put its next message requesting data into the library’s queue, so the library sent my query to the device but gave my code the response to the previous query and went back to waiting for another message from either side, thus making everything one query off until another query call timed out. This was easy enough to solve by making the library use a different process for each device, but it illustrates that you’re not entirely relieved of thinking about state when writing concurrent programs in Elixir. Another issue I’ve had with the message queue is that anything that has your process identifier can send you any message. I ran into this when I was using a different third-party library to send text messages to Slack. The documentation for that library said that I should use the asynchronous send method if I didn’t care about the result. In fact, it described the method as “fire-and-forget.” These were useful but non-essential status messages, so that seemed the right answer for me. Great, until the library decided to put a failure message into the message queue of my process and my code wasn’t written to accept it. Because there was no function that matched the parameters sent by the library, the process crashed, the supervisor restarted it, and it just crashed again, and again, and again until the original condition that caused the problem went away. Granted this was mostly a problem with library’s documentation and was easy enough to solve by adding a callback to my process to handle the library’s messages, but it does illustrate another area where the state of the message queue can surprise you.
The second place that I’ve been surprised to find implicit state is the state of the processes themselves. To be fair, this has only been an issue in writing unit tests, but it does still make life somewhat more difficult. In the OOP world, I’m used to having a new instance of the class I’m testing created for each and every test. That turns out not to be the case when testing GenServers. It’s fine if you’re using the system generated process identifiers, but I often have processes that have a fixed identifier so that any other process can send a message to them. I ended up with messages from one test getting into the message queue of the process while another test was running. It turns out that tests run asynchronously by default, but even when I went through and turned that off, I still had trouble controlling the state of these specially named processes. I tried restarting them in the test setup, but that turned out to be more work than I expected because the shutdown isn’t instantaneous and trying to start a new process with the same name causes an error. Eventually I settled on just adding a special function to reset the state without having to restart the process. I’m not happy about this because that function should never be used in production, but it’s the only reliable way I’ve found to deal with the problem. Another interesting thing I’ve noticed about tests and state is that the mocking framework is oddly stateful, too. I’m not yet sure why this happens, but I’ve found that when I have some module, like the library that talks over TCP, a failing test can cause other tests to fail because the mocking framework still has hold of the module. Remove the failing test and the rest pass without issue, same thing if you fix the failing test. But having a failing test that uses the mocking framework can cause other tests to fail. It really clutters up the test results to have all the irrelevant failures.
Conclusion
I am reminded of a story wherein Jascha Heifetz’s young nephew was learning the violin and asked his uncle to demonstrate something for him. Heifetz apparently took up his nephew’s “el cheapo student violin” and made it sound like the finest Stradivarius. I’m honestly not sure if this is a true story or not, but I like the point that we shouldn’t let our tools dictate what we’re capable of. We may enjoy playing a Stradivarius/using our favorite programming language more than an “el cheapo” violin/other programming language, but we shouldn’t let that stop us achieving our ends. Elixir is probably never going to be my personal Strad, but I’d be happy enough to use it commercially once it matures some more. Most of the issues I’ve described in these postings are likely solvable with more experience on my part, but the lack of maturity would hold me back from recommending it for commercial purposes at this point. When I started using it last June, Dave Thomas’ Programming Elixir was available for version 1.2 and the code was written in version 1.3, although later version were already available. Since then, the official release version has gotten up to 1.6.4 with some significant seeming changes in each minor version. Other things that make me worry about the maturity of Elixir include Ecto, the equivalent of an ORM for Elixir, which doesn’t list Oracle as an officially supported database and the logging system, which only writes to the console out of the box. (Although you can implement custom backends for it. I personally would prefer to spend my time solving business problems rather than writing code to make more useful logs, and I haven’t seen a third-party library yet that would do what I want for logging.) For now, my general view is that Elixir should be kept for hobby projects and person interest, but it could be a viable tool for commercial projects once the maturity issues are dealt with.
About the Author
Narti is a former CC Pace employee now working at ConnectDER. He’s been interested in the design of programming languages since first reading The Dragon Book and the proceedings of HOPL I some thirty years ago.
[1] I’ve no reason to doubt this. I just haven’t tested it myself.
CC Pace had the pleasure of celebrating two very special service awards at our quarterly staff meeting. The first one went to Lee Minai, Senior Accountant, who was recognized for 10 years of service with CC Pace. Over the years Lee has managed the Account Payable/Accounts Receivable function, interfacing with our clients, subcontractors, and account managers with great precision and care. This was a bittersweet celebration for everyone as Lee is retiring to have more time to spend with her growing family, including five grandchildren under the age of 4! Her positive attitude, customer service and warm smile will be greatly missed by everyone – we wish you all the best, Lee!
Philippa (Phil) Fewell, Managing Director of our Lean Agile Practice, joined us back in 1983 when we were known as Cabot Consulting. Over the last 35 years, she came up through the technical ranks managing and delivering financial and technology projects for a wide range of clients, from Fortune 500 to start-ups. CC Pace has had the privilege to be the beneficiary of the wealth of incredible skills and traits that are so admired by Phil’s clients and colleagues. Her versatile Agile experience includes serving as a trainer, coach, consultant, and project manager. Phil has been a role model for demonstrating integrity and excellence by looking out for both our clients and our best interest. And, we think everyone would agree that Phil’s contagious laugh and wit always seem to lighten things up around the office!
To kick off summer in style, at the end of our staff meeting we held a barbeque! This event was not only attended by our current employees, but by several CC Pace alumni as well. We enjoy staying in touch with our alumni and in many cases, have had the opportunity to work with them again. It’s always a good time to catch up with old friends, share some laughs and see what everyone is up to now.
The menu included delicious summer favorites from Dickey’s Barbeque, festive drinks and desserts. And, of course no barbeque would be complete without some corn hole. We also had another game, and while you had to be here to fully enjoy it, all we can tell you is that it involved tattoos and a blindfold!
Wishing everyone a happy summer!
We only have to take a look around to know that while great strides have been made providing technology and applications to help customers with their everyday lives, there is still a long way to go. I don’t mean until life is fully automated, it is more about the refinement needed to what is in use to fully serve its purpose and the public.
Issues customers encounter can be anything from a bifurcated process still needing a combination of personal touch and automation, to technology geared toward some but not all customers, to a limited-scope solution that only addresses part of the customer’s needs (and wants). While the assumption is that it is always quicker to do something online, there are times where that is a fallacy.
Many organizations are realizing there is a gap in their offerings and some have created customer experience (CXP) officers or departments to specifically address the customer experience. The goal for CXP is specifically to “delight” the customer by designing interactions that places the customer’s needs first.
These CXP departments are still nascent in many organizations, but the concept has gained a foothold and momentum. Their focus goes beyond customer service or application usability, they are looking at any and every interaction the customer may have with the organization, across channels, technology and throughout the entire process for their various customer categories using journey maps as a way of mapping out the interactions. In a recent American Banker article ‘Where is everyone going’, Rebecca Wooters, managing director and head of global cards customer experience digital and journey strategy at Citigroup, was quoted saying “Each journey has a starting point or multiple starting points and an intended outcome… What is everything happening in between those two spots, and are we doing what we need to do for the customer to provide a seamless, frictionless experience?”
Allowing a customer to begin a process at the branch, transition to a mobile application to enter their information, and then reach out to the customer support line to continue the process without having to explain their entire situation, re-enter data, or any other duplicative effort would be a nirvana of sort for many organizations. That seamless experience is what organizations strive for but have yet to achieve in the vast majority of cases. That is a world where the tools and information the customer wants and needs are provided, how they want it and when they need it. This foundation will very likely encourage customers to be more independent through self-service transactions, as they will have confidence that they get the answers they need or support they want without wasting time and effort needing duplicative explanations or repetitive data entry.
Does your company have a Customer Experience Division? What changes have been introduced due to this group’s activities? We would love to hear from you!
Introduction
Last June I took over an Elixir based project that involves a central server communicating with various devices over a TCP/IP network. This was my first real exposure to Elixir, so I quickly got a copy of Dave Thomas’ Programming Elixir and went through Code School’s Elixir tutorials so that I could at least start understanding the code I was inheriting. Since then, I’ve spent a fair amount of time changing and adding to this project and feel that I’m starting to come to terms with Elixir and have something to say about it.
My purpose in these posts is not to offer another introductory course in the language but rather to look at some of the features that are said to distinguish it from other languages and think about how different these features really are and how they affect the readability and expressivity of the code that one writes. In this first entry, we’ll look at pattern matching, which constitute the biggest difference between Elixir’s biggest differentiator, and the data structures available in Elixir. A forthcoming post will look at supervision trees, error handling and the handling of state in Elixir.
Pattern Matching
Pattern matching is perhaps the feature that most distinguishes Elixir from traditional imperative languages and, for me, is the most interesting part of the language. Take a statement like:
x = 1
In an imperative language, this assigns the value of 1 to the variable x. In Elixir, it effectively does the same thing in this case. But in Elixir, the equals symbol is called a match operator and actually performs a match between the left-hand side and the right-hand side of the operator. So, we can do things like
{:ok, x} = Enum.fetch([2, 4, 6, 8], 2)
do_something(x)
report_success()
In this case, the fetch function of the Enum module would return {:ok, 6}, which would match the left-hand side of the expression and the variable x would take on the value of 6. We then call the do_something method, passing it the value of x. What would happen, though, were we to call fetch with a position that didn’t exist in the collection we passed it? In this case, fetch returns the atom :error, which would not match the left-hand side of the expression. If we don’t do anything to handle that non-matching expression, the VM will throw an error and stop the process that tried to execute the failed match. (This is not as drastic as it sounds, see the section on Supervisors, below.) All is not lost, though. There are several ways we could avoid terminating the process when the match fails, but I’ll just describe two: the with statement and pattern matching as part of the formal parameters to a function declaration. Strictly speaking, the former is a macro, which I’m not going to cover, but it acts like a flow control statement and quacks like a flow control statement, so I’m not going to worry about the distinctions. Rewriting the above to avoid terminating the running process using a with statement would look like
with {:ok, x} <- Enum.fetch([2, 4, 6, 8], 2) do
do_something(x)
report_success()
else
:error -> report_fetch_error()
end
In this case, we’re saying that we’ll call do_something if and only if the result of calling fetch matches {:ok, x}; if the result of calling fetch is :error, we’re going to call report_error, and if the result is something else, which isn’t actually possible with this function, we’d still throw an error. We can actually have multiple matches in both the with and the else clauses, so we could also do something like:
with {:ok, x} <- Enum.fetch([2, 4, 6, 8], 2),
:ok <- do_something(x) do
report_success()
else
:do_something_error -> report_do_something_error()
:error -> report_fetch_error()
end
Here, do_something will still not be executed unless the result of fetch matches the first clause, but the else clauses are executed with the first non-matching value in the with clauses. If do_something also just returned :error, though, we’d have to separate this out into two with statements.
The other way we could handle the original problem of the non-matching expression would be to use pattern matching in the formal parameters of a set of functions we define. For example, we could express the code above as:
do_something(Enum.fetch([2, 4, 6, 8], 2))
def do_something({:ok, x}) do
result = … # :ok or :error
report_do_something_result(result)
end
def do_something(:error) do
report_fetch_error()
end
def report_do_something_result(:ok) do
report_success()
end
def report_do_something_result(:error) do
# whatever it takes to report the error
end
In this case, we’re using pattern matching to overload a function definition and do different things based on what parameters are passed instead of using flow control statements. The Elixir literature tends to say that this is actually preferable to using flow control statements as it makes each method simpler and easier to understand, but I have my doubts about it. I find that I tend to duplicate a lot of code when use pattern matching as a flow control mechanisms. To be fair, I’m learning more and more techniques to avoid this, but in the end I suspect that the discouragement of flow control structures and, perhaps more importantly, the lack of subclassing makes the code harder to understand and makes it harder to avoid duplicating code than I’d like.
Sometimes, too, I feel like the cure for avoiding this kind of duplication can be worse than the disease. One technique I’ve seen used is essentially to use reflection, and I found that code very hard to follow and some of the code just got duplicated between modules instead of being duplicated in a single module. There are other techniques for dealing with this kind of duplication, too, but I can’t shake the feeling that I’m being pushed into making the code less expressive when trying to remove duplication when other languages would have made removing the duplication easier and more obvious.
Another concern I have around this form of overloading methods through pattern matching is that the meaning of the patterns to match isn’t always obvious. For example looking at two functions like:
def do_something(item, false) do
…
end
def do_something(item, true) do
…
end
How do you know what the true and false mean? Sadly, you have to go back and find the code that’s calling these functions to see what the distinguishing parameter represents. You can actually write the declarations to be more intention revealing:
def do_something(item, false = _active) do
…
end
def do_something(item, true = _active) do
…
end
But the majority of the code I’ve looked at is written in the former style that doesn’t reveal its intentions as well as the latter.
Pattern matching is at once both the most intriguing and a sometimes troubling element of the language. I find it an interesting concept, but I’m still not sure whether it’s something I’m really happy about.
Data Structures
Elixir displays a curious dichotomy in regards to data structures. On the one hand, we’re told that we shouldn’t use data structures because they represent the bad-old object oriented way of doing things. On the other hand, Elixir does allow one to create structs, which define a set of fields, but no behavior, and set default values for them. Structs are really just syntactic sugar on top of Elixir’s maps, though. An Elixir map is a set of key/value mappings and a struct enforces the set of keys that one can use for that particular map. Otherwise they’re interchangeable, so I’m going to ignore structs for the rest of this discussion. Elixir offers two other data structure that aggregate data: lists and tuples. Conceptually Elixir lists are pretty much like a list in other programming languages. (Remembering that all of these data structures are immutable in Elixir.) The documentation says that there are some low-level implementation differences that make Elixir lists more efficient to work with than in other languages, but I haven’t concerned myself terribly about this. Finally, in terms of aggregating data, we have tuples. One can use a tuple much like a list, except that again there are implementation details that make they more efficient to use in some situations than lists, while in other situations the lists are more efficient. In practice, I’ve mostly seen tuples to be used when one wants to match a pattern and lists used when one is just storing the data. One somewhat contrived example of all of this and then some discussion:
So, what’s going on here? We’re again using pattern matching to expect the function get_grades to return a tuple consisting of the atom :ok and a map containing two lists of three elements each, where the name of the second student in the list must be “student2,” just to show that we can do a match to that level.
While more specific than is typical, the pattern of returning status and response is fairly common in Elixir. This supposedly obviates a lot of exception handling, but to my way of thinking, it really just replaces it with with statements, as described previously. I’m not convinced that it makes that much difference.
I think that the prevalent use of atoms, on the other hand, makes a large difference. Sadly, it’s a negative difference in that atoms turn into another form of magic numbers (in the code smell sense). Elixir has no way to define a truly global constant, so there’s actually no way around polluting one’s code with these magic numbers and there’s no compiler support for when one mistypes one of them. For example, consider some hypothetical code dealing with a TCP socket:
def send_stuff(socket, stuff) do
with :ok <- :gen_tcp.send(socket, stuff) do
:ok
else
{:error, :econnrefused} -> …
{:error, :timeout} -> …
end
end
def open_socket(address, port, options) do
with {:ok, socket} <- :gen_tcp.connect(address, port_options) do
{:ok, socket}
else
{:error, :econnnrefused} -> …
{:error, :timeout} -> …
end
end
There’s nothing to tell me that I’ve accidentally added an extra “n” to :econnrefused in the open_socket function until it it turns into a runtime error. (This is also the kind of code that will often not get unit tested because it’s hard to deal with. I haven’t had to write any code at this level yet, so I’m unsure if I could mock gen_tcp or not, but that’s the only way I could think of to ensure that all the error handling worked correctly.)
Conclusion
I find Elixir’s pattern matching a very interesting feature of the language. Sometimes I think that it’s a nice step towards adding assertions as first-class elements of production code. At other times, though, I wonder if it really adds to the readability of the code. For example, is the send_stuff example really more readable than:
That being said, I often vacillate between Java’s checked exceptions and .NET’s unchecked exceptions. Elixir has pushed me much more towards making exceptions checked by default since that makes sure that I think about them when .NET and Elixir let me forget about them, often to my detriment.
Unless and until Elixir offers truly global constants, however, I find myself distrusted the use of atoms in pattern matching to distinguish between functions. I worry that I have too much code that’s like:
Granted that I could probably do more to avoid this, but I also feel like this would make the code less expressive.
Next time we’ll look at supervision trees, error handling and handling state in Elixir.
About the Author
Narti is a former CC Pace employee now working at ConnectDER. He’s been interested in the design of programming languages since first reading The Dragon Book and the proceedings of HOPL I some thirty years ago.
CC Pace is proud to announce the launch of our most recent market survey in which we explore some of the current trends in mortgage lending, including improving the customer experience, going digital and more. We invite our readers to participate by clicking the link below. The survey takes less than 10 minutes to complete and all data collected will be treated as confidential.
Well known in the mortgage industry for our work in process engineering and successful project execution, CC Pace has been conducting industry surveys for our clients for years, gathering market intelligence and preparing trend analyses. Recently, we’ve been increasing the frequency with which we’ve conducted surveys for consumption by a broader audience within the industry.
Our last survey (get it here), was extremely successful, with many industry publications touting the paper’s availability and various statistics from the paper were quoted by numerous sources on social media. Most gratifying, Austin Kilgore, editor in chief at National Mortgage News, chose to use data from our report to illustrate several of his points in an article entitled “Five Trends that will shape the mortgage industry in 2018”.
By participating in the survey, you will get an advance copy of the resulting white paper and be the first in line to get valuable insights as to how your plans and strategies relate to those of your peers and competitors. Surely this is worth ten minutes of your time (actually, SurveyMonkey tells us that most early respondents are completing it in just over 7 minutes).
CC Pace recently partnered with The Stallions, a highly regarded team in the Washington Metro Cricket League (WMCL), as a corporate sponsor. Ashok Komaragiri, Lead Technology Consultant at CC Pace, is a member of the team and presented this opportunity to CC Pace.
We sat down and had a conversation with Srinivas Mallapuram, captain and co-founder of The Stallions Cricket Team, to learn more about cricket and what this partnership means for both The Stallions and CC Pace.
Can you explain the basics of Cricket to us?
Cricket traces its origins to the late 16th century in England; it is now played in more than 125 countries. In terms of popularity, it is second only to soccer. A Cricket match is played between two teams of 11 players on a cricket field. Both teams take turns ‘batting’ and ‘bowling’. The objective of the batting team is to score as many runs as possible during their turn, while the bowling team tries to limit the number of runs scored by the batting team. In the second part of the game, the two teams switch roles and the team that formerly batted must ensure their opponents do not score as many or more runs as they did. Now, I don’t want to go too deep in explaining the rules of cricket here—there’s always Google for that, right?
Tell us about cricket in the DMV area.
Cricket has become a very popular sport in the DC Metro area, as evidenced by the number of different leagues in this area. Cricket is typically played with a leather ball at the professional level, but most leagues in the DMV area substitute the leather ball with a hard-tennis ball (looks like a regular tennis ball but is heavier). There are many different cricket leagues in this area; WMCL is one of the most prominent leagues.
The Stallions are in the WMCL – can you tell us more about that league?
The WMCL was formed in 2009. As of this year, there are 34 teams across two divisions (16 in Div1 and 18 in Div2). This league enjoys more popularity and participation as compared to other hard-tennis ball leagues, having close to 1,000 active players. The league has three cricket fields: one in Herndon, Centreville, and Reston. The games are played using the T20 format and are played over the weekend. I am proud to say that our team, The Stallions, are always considered one of the top contenders for the upper division title.
How did the Stallions team get started?
Our team was formed in 2010 by myself and a few other cricket enthusiasts. We now participate in 3 different hard-tennis ball leagues in the DMV area. We have a common pool of players, who play in these 3 different leagues, however some players only play in one of the 3 leagues. Our combined pool is comprised of 75 players. We are a highly successful team, and are generally considered one of the top teams in all 3 leagues. We were the runners-up in the 2017 Spring Season championship.
How’s this WMCL 2018 Spring season been so far for Stallions?
Of the 4 matches we have played so far this season, we won two. The two matches we lost were closely contested games right up to the very end. Overall, I am happy with the team’s performance, we would have liked more wins under our belt considering we have some tough games coming up. We are focused on winning our upcoming matches to secure a place in the playoffs.
How do the Stallions feel about their partnership with CC Pace?
Over the past several years, the different counties in the DMV area have tremendously encouraged and promoted Cricket in every way they can. Recently, some corporate companies have also extended their support by either sponsoring the leagues themselves, or individual teams. We are fortunate and thrilled that CC Pace has decided to sponsor our team in the WMCL for this year. At the risk of sounding clichéd, I think, fundamentally, our team’s principles align with those of CC Pace, in that we both strive for excellence, and I believe that makes a sound foundation for a good partnership. CC Pace, along with offering technology and business consulting services, also participates in a variety of community outreach programs; in true partnership, The Stallions have already joined in and started to participate with the company in these community events.
Interested in catching a match and cheering on the Stallions?
You can view the Stallions schedule and game results on the WMCL’s website - http://wmcl.net
In our previous blog What Really Matters to Millennials Today, we discussed that more than one third of the workforce today are millennials. Employers are now asking themselves, what can we do to appeal this demographic?
This list is actually not limited to just millennials. Everyone, regardless of age, wants to feel passion and purpose, desires flexibility, uses social media and has changed the way they now job search. However, it is the millennials who have driven more companies to consider the importance of addressing what they have to offer. Are you ready to revamp and do what it takes to attract millennials?
Most Agile transformation efforts in the government begin with the Scrum process. However, many agencies feel that they have reached a plateau and are ready to move through to the next logical steps. Improving digital services delivery and getting working software into the users’ hands shouldn’t stop with just Scrum. As agencies progress in their Agile transformation, they begin to see the value of adding the Agile engineering practices, such as Test-Driven Development and Continuous Integration to improve code quality and the downstream delivery of fully functional and tested software. And what about the challenges of scaling Agile for very large projects? What might a strategic progression for Agile transformation look like? This will be the focus of our ninth Agile in Government workshop, Agile Engineering, SAFe and DevOps: A Roadmap to Adoption at the Potomac Forum, Willard InterContinental Hotel on Thursday June 14, 2018.
CC Pace spent an informative day at the Center for Innovation Technology (CIT) event in Herndon, VA: Lean Agile DC. Jason Velentino (Director, Digital Reliability Engineering at Capital One) kicked off the conference with a great presentation on DevOps and his journey through incorporating cloud and a DevOps culture at such a large organization. It is rewarding for CC Pace to have been a part of the Agile adoption at Capital One, providing Agile Coaching and Training over the past five years and to see the evolution of Agile, which Capital One has made part of their everyday culture.
Another great presentation and discussion on Agile Engineering was lead by Jose Mingorance, and Carlos Rojas of Fannie Mae. They have pulled together a lot of ideas from Agile leaders to provide Fannie Mae with an exciting assessment and plan to drive business value throughout their organization through advancing Agile engineering practices. It was interesting to see their plans and the excitement surrounding this initiative.
Finally, Dean Chanter, also from Capital One, lead a great discussion on Joshua Kerievsky’s Modern Agile principles. Dean spoke about his journey towards ‘modern Agile’ at Capital One and how those principles are at the cornerstone of their advancement in their Agile transformation as an organization. As Capital One continues their trajectory into being Agile leaders in the Financial Services market, this will be an interesting case study to keep an eye on! We look forward to next year and seeing how everyone has progressed.
Volunteers from across Northern Virginia came together to take part of an exciting and historic event called 2018 Food Fight— supports the Nation’s Fight Against Hunger sponsored by Feed My Starving Children. An estimated 6,200 children die worldwide each day from malnutrition and hunger-related diseases. This organization is working to get food to those in need as quickly as possible by hosting events like this one. We want to express a special thank you to all the CC Pacers who participated in the extraordinary event.
Our CC Pace team of volunteers met up at the Dulles Expo Center in Chantilly, Virginia to join other community members to participate in a huge, weekend-long event to pack over 3.5M meals for starving children around the world. Dressed in their bright blue CC Pace shirts and lovely hair nets, they rocked out to music and worked together to pack 1,440 meals at their station. During their time slot alone, all of the volunteers packed more than 100K meals. Imagine all the children those meals will feed!
If you would like to learn more about or support this organization, please check out their website https://www.fmsc.org/. You can also see how these meals are in making a difference in the lives of those who receive them by visiting this link 2018foodfight.com/see-the-impact.
#GivingBack
In part 1, we discussed how a new team could help lay out the foundation of a social contract between itself and the larger organization. While that works at the macro level, what about the micro, day-to-day interactions within a team? The focus on a social contract can be a powerful tool in helping a team to perform at its peak. At its core, this commitment between team members strengthens trust, set expectations, and lets the team push beyond a previously understood comfort level. Both sides of an interaction must be dedicated to fulfilling their part of the equation.
What are some way this could look like on a day to day basis?
Take the simple act of a code review. At a surface level, the developer running the review would go over a high level overview of the card being worked. They would walk through the basic coding that was done, and do a brief demo of the new functionality. The reviewer nods along, perhaps pointing out an item or two regarding coding standards, and moves along without a deeper probing of the work done. In a scenario with a strong social contract defined, this would be seen as falling well short of what is expected of both team members. The developer running the review would do a fuller explanation of the goal of the card, and tie it into the larger picture of the application or the organization’s goals. The reviewer would ask more intensive questions, including, for example, how test-driven development concepts were used to work the card. The demo of the new functionality would not only show the happy path, but push at the edge cases that were considered. The reviewer would prod on the design and maintainability of the code. The goal of the exercise would be understood to not just check a box, but to provide value to each member of the team, and to the overall team itself. There would be increased confidence in the quality of the code and the product. There would be increased knowledge-sharing amongst the team leading to less stove piping of expertise. Lastly, team members would be building trust between each other so that they could feel more comfortable communicating questions or out-of-the-box ideas.
The same idea can be applied to team-wide activities. Does your team do a daily stand-up and regular retrospectives? This is an area where muscle memory can set in, and team members can start to just go with the flow. If they follow the concepts of the social contract, team members know that they are responsible to make sure the team is generating value from these. Put down the phone during the meeting. Make eye contact when addressing the team. Commit to putting into action the steps generated to make the team work better.
The big picture with the social contract is to ensure team members are fully engaging in the tasks of the team. Confidence and respect, a sense of responsibility to each other and the larger team builds organically over time. Only then can teams truly hit the “perform” staging of “Form-Storm-Norm-Perform”, and deliver the full value to the organization and its customers.
Can you imagine a world without engineering? It’s a tougher question to answer than you might think. Many people do not actually know the extent to which we rely on engineering for our daily lives to function, and the amount of work that has gone into it by different types of engineers.
The discipline of engineering is one of the oldest, arguably as old as civilization itself. The first engineers were those who developed the lever, the pulley and the inclined plane. Egyptian engineers designed and built the Pyramids, and Roman engineers conceptualized the famous aqueducts. Today, engineering covers a broad range of disciplines, all devoted to keeping the “engine” running — a world without engineering would soon come to a standstill.
In a recent conversation, I answered the usual “What does CC Pace do?” question with my standard response regarding our services, to which she replied, “Oh, you’re process engineers!” Her response was compact, narrowly focused, and remarkably spot on. With people processes and systems processes at the heart of much of what we at CC Pace do, yes, we are process engineers, yet it had never occurred to me to describe us as such.
Quoting liberally from Wikipedia, process engineering focuses on the design, operation, control and optimization of a series of interrelated tasks that, together, transform the needs of the customer into value-added components and outputs. Systems engineering is a close corollary activity that brings interdisciplinary thinking to focus on how to design and manage complex systems, beginning with discovering the real problems that need to be resolved and finding solution to them. That’s what we do here at CC Pace in a nutshell.
Some folks make the mistake of thinking business processes are in place to only ensure internal controls remain strong and to make people accountable for what they are doing. In fact, business processes constitute all the activities your company engages in—using people, technology, and information—to carry out its mission, measure performance, serve customers, and address the inevitable challenges that arise while doing so. Processes determine the effectiveness and efficiency of your company’s operations, the quality of your customers’ experience and ultimately, your organization’s financial success.
At CC Pace, we pride ourselves in achieving organizational excellence by being the industry leader in business process and technology engineering. We are dedicated to driving innovation and delivering exceptional quality in everything we do. As systems and process engineers, we help our clients streamline, standardize and improve their processes to retain a competitive edge. You see problems; we see solutions.
Last month at CC Pace’s staff meeting we had the privilege to honor Lauren Iezzoni with a Service Award marking her 5 Year Anniversary with the company. Lauren performs dual roles, working with our Enterprise Solutions group as an Agile Training Coordinator, and with our Marketing team as a Graphic Designer. Over her time at CC Pace, her keen organizational and customer service skills have resulted in her ability to manage our training clients and vendors, while increasing our public training offerings. In addition, she has used her artistic creativity to work with Marketing to revamp the look and feel of not only our collateral, but our office environment as well! Thank you, Lauren!
Coinciding in celebration last month, we held our Annual Party at Ruth’s Chris, which marked the 38th Anniversary of the company. Team members from across the country were in attendance and having everyone together, although it was brief is always a festive time for the company.
As part of our celebration of 38 years, we held a food drive to benefit the Lorton Community Action Center’s food bank, a local non-profit organization that supports the community in southern Fairfax County. We set a goal to collect 380 pounds of food, 10 pounds for every year CC Pace was in business, and included a competitive element breaking the company into teams. The friendly competition between our 4 teams created a lot of enthusiasm, energy and corporate spirit. It was a close race right up to the end, with our winning team contributing more than 300 lbs. of food! We are proud to report that all together, we far exceeded our goal and collected over 800 lbs of food! A big shout out to the winning team – congratulations to our Financial Services and Government groups!
This post, The No. 1 Thing That Causes Millennial Employees to Quit, states that more than one third of the workforce in the United States is between the ages of 18 and 34 years old. It also points out that millennials are currently the largest group of workers in America.
Dominating the recruiting pool, millennials have made it well known that if they are not happy in their current work environment, they will move on without hesitation. So, what can companies do to meet the needs of millennials? It seems the answer is not that difficult to find – to recruit and retain these workers, employers simply need to provide them a corporate culture that provides positivity, flexibility and the latest technologies.
Companies need to take a closer look at what they offer, and make the necessary changes to not only attract, but keep, these valuable employees who are the future of their organizations.
It’s a scenario we’ve all been a part of before. To shake things up, your Agile teams are being restructured. After the initial shuffle, the team gets together for a first meeting to figure out how it is going to work. Introductions are made, experiences are shared. Maybe a team lead is named. It’s a heady time full of expectations. Following the cycle of Forming-Storming-Norming-Performing, phase one is off to a good start.
At the first team retro, a better understanding of what everyone brings to the team starts to take shape. Relationships and communications within the team, as well as other players within the organization, take root. The team also starts to get a sense of where there are some gaps. Maybe it’s a misunderstanding of how code reviews work, or how cards are pointed. Storming has happened, and the team is ready to begin the transition to the Norming phase.
I’d suggest that team norms, which tend to be prescriptive in nature, falls short of what the stakeholders are hoping it will. Instead, I’d suggest that a social contract is a better concept to work towards.
A social contract is a team-designed agreement for an aspirational set of values, behaviors and social norms. They not only set expectations but responsibilities. Instead of being focused on how individual team members should approach the work of the team and organization, it lays out the responsibilities of the team members to each other. It also lays out the responsibilities and expectations between the team and the organization.
What would this type of contract look like? It should call out both sides of a relationship. An example of part of a social contract may look like this:
The Team promises to place value through deliverable software as the highest goal to the organization, as defined by the Product Owner
The Team promises to raise any obstacles preventing them from delivering value immediately
The Organization promises to address and remove obstacles in a timely manner to the best of their ability
The Organization promises to maintain reasonable stability of the team so that it has the opportunity to mature and reach its highest potential
In the spirit of the social contract, this should be discussed and brainstormed with open minds and constructive dialog with both sides of the social equation. In truly Agile fashion, it should also be considered an iterative process, and reviewed from time to time to ensure the social contract itself is providing value.
Almost everywhere we look, we see the signs of a rapidly progressing transformation to an online, digital future, in the way we communicate, consume entertainment, shop and manage our finances. Very surely more and more aspects of our daily lives are changing at a clip unlike anything we’ve seen before. Is it possible the banking and mortgage industries are immune to this transformation? Absolutely not.
But disturbingly, a survey by Mindmatters Technologies Inc., a firm that specializes in helping clients maximize innovation in new product development, found that 81% of US businesses do not have the resources needed to fully pursue the innovations and new ideas capable of keeping their companies ahead in a competitive marketplace. Polling from CC Pace’s own recent survey (Mortgage Banking & Technology: Lenders’ Perspective) found that thus far, fully 80% of lenders have failed to take substantive steps towards creating the capability of offering their customers a truly end-to-end digital mortgage experience.
Banks and lenders continue to find themselves trapped by mature, complex processes, products, and systems, and the cost of breaking these chains to enter the digital age will only continue to mount. Further, lenders exhibit little confidence that their software providers are doing enough to help them with the transition. Evidence of this concern is validated in our recent survey where we found that 64% of lenders today continue to be “unhappy with” or “resigned to” their current technology provider.
Even as many in the banking industry struggle to overcome inertia in their move towards digital, they are feeling threatened by “outsiders” who are not as bound by the past, thus are able to more freely design, build, and launch solutions that offer cutting edge technology and processes that better meet the demands of today’s consumer. Whether motivated by fear of survival or the desire to be an industry leader, one thing is for sure: lenders can ill afford to sit idly by, waiting for the future to arrive.
Consequently, lenders are increasingly deciding to take the future into their own hands. For some, that means moving away from traditional vendor-supported platforms in favor of developing technology in-house, but such moves are not for the faint-hearted. Many more are finding that the most cost-effective (and risk averse) strategy for moving into the digital age is to begin building on top of their existing platforms to effectively cross the chasm. Bolting new capabilities onto legacy systems from among a host of FinTech upstarts, coupled with adopting aggressive process reengineering and business transformation projects can allow them to attain new benchmarks of success.
With many lenders lacking the time and resources to sustain a complete technology overhaul and engage in an end-to-end business transformation, often they turn to third-parties, including CC Pace, to help pave their way to success in the digital age. Employing innovative ideas, judiciously selected technology additions, and a well thought out approach to reengineering can allow almost any lender to successfully reposition themselves to attain their digital transformation goals.
I’ve always said, “it all comes down to execution”. A key component to successful execution is knowing that successful process reengineering is less of an IT effort and more of a strategic business design project. For lenders to catapult themselves successfully across the chasm into the digital age, it will require a balanced approach of taking the future into their own hands, designing a realistic roadmap, finding the right partner to work with, and executing flawlessly. You see problems; we at CC Pace see solutions.
Every company has their own Corporate Culture, which characterizes the qualities of a work environment. Corporate culture is a key factor in both retaining and attracting talent, with 80% of Millennials say they are looking for cultural fit when seeking potential employers.
CC Pace recently rolled out a new vision and central to this vision is a focus on our people, which we believe are our greatest asset. Keeping that in mind and the significance of corporate culture, we surveyed numerous team members from various locations and all levels for their view of our current culture.
Each team member was given only one of the questions below to respond to, here is a summary of what they had to say:
Describe CC Pace’s corporate culture in three words?
“Flexible, Supportive and Team-oriented”
“Supportive, Respectful (value’s and respect’s everyone’s input) and People-Centric”
“Flexible, Family-oriented and has a Relaxed Environment – And, we all share the love of GOOD FOOD!”
Can you please tell us one thing that you feel makes our workplace culture unique?
“The work/life balance message truly walks the talk.”
“We do a great job at crossing functional business lines to pull together resources (when feasible and available) to make a project work.”
“The amount of input we have gives us the opportunity to express our thoughts to not only our peers but our management team as well.”
Can you please describe CC Pace’s corporate culture?
“CC Pace has a good team-based culture with employee participation on all levels. CC Pace values individual employees and encourages them to speak up and share ideas. They value integrity and put a lot of emphasis on the quality service they provide to their clients.”
“At CC Pace, our corporate culture comes from our unwavering commitment to helping clients’ succeed. People are our most valuable asset. We strive to create a collaborative, energetic environment that provides meaningful work and supports professional development.”
CC Pace understands a “one-size-fits-all” approach towards employees is not the answer to having a positive corporate culture, but rather one in which openness to new ideas and flexibility are encouraged. As our employee survey highlighted, we have tried to create a positive environment that values employees and is conducive to both individual and corporate success.
Are you ready to work somewhere your talents, ideas and contributions will have a true impact? If the answer is yes, and this all sounds good to you, we invite you to consider joining our team.
Introduction
This is the second in a series of posts about our experience using Visual Studio Team Services (VSTS) to build a deployment pipeline for an ASP.NET Core Web Application. Future posts will cover release artifacts and deployment to Azure cloud services.
Prerequisites
It’s assumed that you have an ASP.NET Core project set up in VSTS and connected to a Git repository.
See the previous blog post for details.
Goal
The goal of this post is to set up your ASP.NET Core project to automatically build and run Unit Tests after every commit to source code repository (I.e. Continuous Integration).
Here is a video summarizing the steps described below:
In VSTS, go to Build under the Build and Release tab
Select “ + New Definition”
Select ASP.NET Core Template
Enter any Name that can help you to identify this build.
Select an appropriate Agent queue. In this example, we will use Hosted VS2017. Use this agent if you’re using Visual Studio 2017 and you want the VSTS service to maintain your queue.
To simplify the process, use the default value for other fields.
Go to “Trigger” and Enable continuous integrations. This will cause a build to automatically kick off after every code commit.
Save the definition.
Adding a Test Project to the Solution
Open the solution (from the previous post) in Visual Studio.
Add a new Test Project.
Select .NET Core > Unit Test Project. We will name this project MyFirstApp.Tests. Note: the default build definition will look for test projects under folders that end with the word, “Tests“. So, make sure that a new folder that contains this word is created when you add your Unit Test Project.
For a proof of concept, we are going to write a dummy Test Method. Enter the following code in UnitTest1.cs
Rebuild the project.
Commit the changes locally and push it to the remote source repo.
Back in VSTS, you can see that a Build has been triggered.
Click on the build number #2018XXXX.X to view the details of the build. Normally this will take a few minutes to complete.
Ensure all of the steps passed. You can click on each step to view log details.
What’s Next?
We’ll demonstrate how to deploy builds to different environments, either via push-button deployment or triggered automatically after each build (I.e. continuous deployment).
Stay tuned!
Introduction
This is the first in a series of posts about our experience using Visual Studio Team Services (VSTS) to build a deployment pipeline for an ASP.NET Core Web application. Future posts will cover automated builds, release artifacts and deployment to Azure cloud services.
The purpose of this post is to show how to create a new Visual Studio Team Services, or VSTS, project, set up a Git code repository and integrate everything through your Visual Studio IDE.
Here is a video summarizing the steps described below:
Creating a New Project
If you haven’t already done so, create a VSTS account using your Microsoft Account. Your Microsoft Account is the “owner” of this VSTS account.
Log into VSTS. By default, the URL should look like (VSTS account name).visualstudio.com. For this demo, The VSTS account that we will be using is https://ccpacetest.visualstudio.com, and the Microsoft user is CCPaceTest@outlook.com
Create a new project. This Microsoft Account is the “owner” of this project.
4. For this demo, we will select “Git” as our Version Control and “SCRUM” as the work item process.
Connecting VSTS Project to Visual Studio IDE
There are many ways you can work on your project. A list of supported IDE’s is listed in the dropdown below. For this demo, we will use Visual Studio 2017 Professional Edition.
Click “Clone in Visual Studio”. This will prompt you to launch your Visual Studio.
If this is your first time running Visual Studio, you will be prompted to log in to your Visual Studio account. To simplify the process, log in to the Microsoft Account that you used to create the demo project previously. This should give you the admin access to the project.
Go to View > Team Explorer > Manage Connection. Visual Studio will automatically show you a list of the hosted repositories for the account you used to log in. If you are following the previous steps, you should be able to see HelloWorld.Demo project. If you are not seeing a project that you are expecting to have access to, verify the account you log in to or check with the project owner to make sure you are given the right permission.
5. Connect to the project.
6. If this is the first time you are accessing this project in your local environment, you will be prompted to clone the repository to your local git repository.
Initial Check In
Within the Team Explorer, click the Home button. Under the “Solutions”, select “new…”. Using this method will ensure the solution is added to the right folder.
For this Demo, we will create a new project using the ASP.NET Core Web Application template. The solution name doesn’t have to be the same as the project name in VSTS, but to avoid confusion, it is recommended to use the same name.
Once the solution is created, go back to Team Explorer and select “Changes”, you should be able to view all the items you have just added.
Enter a comment and click “Commit All”. This will update your local repository.
To “Push” these changes to the remote Repository, click “sync”, and finally “push”.
You can verify this by logging into your VSTS, go to “Code” and you should be able to see all of the codes you have just checked in.
Collaborating with other Team Members
You can add additional members to your project by going to the Settings > Security
Please note that:
a: If your VSTS account is Azure Active Directory backed, then you can only add email addresses that are internal to the tenant.
b: You must add email addresses for users who have “personal” Microsoft accounts unless your VSTS account uses your organization’s directory to authenticate users and control account access through Azure Active Directory (Azure AD). If new users don’t have Microsoft accounts, have them sign up.
Can you believe it is already 2018? Think about all the technological advances there have been in the last 10 years… no actually make that 5 years - it is truly unbelievable! All of this new technology has created a culture of “now”. Interested in watching something on TV – just stream it, “now”. Do you want to ask someone a quick question, no matter where they are – just shoot them a text, “now”. Do you want to order something and have it delivered today – just get online and order it, “now”.
Move that thinking to the human resources or recruiting department of an organization where they think, if only we could start to screen for this position “now”. If only we can confirm this candidate is as good in person, as they are on paper “now”. This is where the advantage of video interviewing comes into play.
This article, 15 Advantages of Video Interviews You Didn’t Know About, discusses how companies, both big and small, are using this technology to screen candidates, streamline the hiring process and save these organizations time and money. A video interview is a great way to connect with a potential employer, so be prepared as you begin your next job search and make sure you are camera ready!
‘Agile’… ‘Lean’… ‘Fitnesse’… ‘Fit’… ‘(Win)Runner’… ‘Cucumber’… ‘Eggplant’… ‘Lime’… As 2018 draws near, one might hear a few of these words bantered around the water cooler at this time of year as part of the trendy discussion topic: our personal New Year’s resolutions to get back into shape and eat healthy. While many of my well-intentioned colleagues are indeed well on their way to a healthier 2018, many of these words were actually discussed during a strategy session I attended recently – which, surprisingly, based on the fact that many of these words are truly foods – did not cover new diet and exercise trends for 2018. Instead, this planning session agenda focused on another trendy discussion topic in our office as we close out 2017 and flip the calendar over to 2018: software test automation.
“SOFTWARE TEST AUTOMATION?!?” you ask?
“SERIOUSLY – cucumbers and limes and fitness(e)?!?”
This thought came to mind after the planning session and gave me a chuckle. I thought, “If a complete stranger walked by our meeting room and heard these words thrown around, what would they think we were talking about?”
This humorous thought resonated further when recently – and rather coincidentally – a client asked me for a high-level, summary explanation as to how I would implement automated testing on a software development project. It was a broad and rather open-ended question – not meant to be technical in nature or to solicit a solution. Rather, how would I, with a background in Agile Business Analysis and Testing (i.e. I am not a developer) go about kickstarting and implementing a test automation framework for a particular software development project?
This all got me thinking. I’ve never seen an official survey, but I assume many people employed or with an interest in software development could provide a reasonable and well-informed response if ever asked to define or discuss software test automation, the many benefits of automated testing and how the practice delivers requisite business value. I believe, however, that there is a substantial dividing line between understanding the general concepts of test automation and successfully implementing a high-quality and sustainable automated testing suite. In other words, those who are considered experts in this domain are truly experts – they possess a unique and sought-after skill set and are very good at what they do. There really isn’t any middle ground, in my opinion.
My reasoning here is that getting from ‘Point A’ (simply understanding the concepts) to ‘Point B’ (implementing and maintaining an effective and sustainable test automation platform) is often an arduous and laborious effort, which unfortunately, in many cases, does not always result in success. At a fundamental level, the journey to a successful test automation practice involves the following:
Financial investment: Like with any software development quality assurance initiative, test automation requires a significant financial investment (in both tools and personnel). The notion here, however – like any other reasonable investment – is that an upfront financial investment should provide a solid return down the line if the venture is successful. This is not simply a two-point ‘spike’ user story assigned to someone to research the latest test automation tools. To use the poker metaphor – if you are ready to commit, then you should go all-in.
Time investment: How many software development project teams have you heard stating that they have extra time on their hands? Surely, not many, if any at all. Kicking off an automated testing initiative also requires a significant upfront time investment. Resources otherwise assigned to standard analysis, development or testing tasks will need to shift roles and contribute to the automated testing effort. Researching and learning the technical aspects of automated testing tools, along with the actual effort to design, build out and execute a suite of automated tests requires an exceptional team effort. Reassigning team tasks initially will reduce a team’s velocity, although similar to the financial investment concept, the hope is significant time savings and improved quality down the line in later sprints as larger deployments and major releases draw near.
Dedicated resources with unique, sought after skill sets: In my experience, I’ve seen that usually the highest rated employees with the most institutional/system knowledge and experience are called on to manage and drive automated testing efforts. These highly rated employees are also more than likely the most expensive, as the roles require a unique technical and analytical skill set, along with a significant knowledge of corresponding business processes. Because these organizational ‘all-stars’ initially will be focused solely on the test automation effort, other quality assurance tasks will inherently assume added risk. This risk needs to be mitigated in order to prevent a reduction in quality in other organizational efforts.
It turns out that the coincidental internal automated testing discussion and timely client question – along with the ongoing challenge in the QA domain associated with the aforementioned ‘Point A to Point B’ metaphor – led to a documented, bulleted list response to the client’s question. Let’s call it an Agile test automation best-practices checklist. This list can be found below and provides several concepts and ideas an organization could utilize in order to incorporate test automation into their current software testing/QA practice. Since I was familiar with the client’s organization, personnel and product offerings, I could provide a bit more detail than necessary. The idea here is not the ‘what’, as you will not find any specific automation tools mentioned. Instead, this list covers the ‘how’: the process-oriented concepts of test automation along with the associated benefits of each concept.
This list should provide your team with a handy starting point, or a ‘bridge’ between Point A and Point B. If your team can identify with many of the concepts in this list and relate them to your current testing process and procedures, then further pursuing an automated testing initiative should be a reasonable option for your team or project.
More importantly, this list can be used as a tool and foundation for non-technical members of a software development team (e.g. BA, Tester, ScrumMaster, etc.) in order to start the conversation – essentially, to decide if automated testing fits in with your established process and procedures, whether or not it will provide a return on investment and to ensure if you do indeed embark down the test automation path, that you continue to progress forward as applications, personnel and teams mature, grow and inevitably, change. Understand these concepts and when to apply them, and you can learn more about cucumbers, limes and eggplants as you progress further down the test automation path:
To successfully implement and advance an effective and sustainable automated testing initiative, I make every effort to follow the following strategy which combines proven Agile test automation best-practices with personal, hands-on project and testing experience. As such, this is not an all-inclusive list, rather just one IT consultant’s answer to a client’s question:
For folks new to the world of test automation and for those who had absolutely no idea that ‘Cucumber’ is not only a healthy vegetable but is also the name of an automated testing tool, I hope this blog entry is a good start for your journey into the world of test automation. For the ‘experts’ out there, please respond and let me know if I missed any important steps or tasks, or, how you might do things differently. After all, we’re all in this together, and as more knowledge is spread throughout the IT world, the more we can further enhance our processes.
So, if you’ll excuse me now, I’m going to go ahead and plan out my 2018 New Year’s resolution exercise regimen and diet. Any additional thoughts on test automation will have to wait until next year.
Giving back to our communities is important to CC Pace and we believe it is essential for us to involve ourselves as an organization and as individuals, to contribute to making our communities a better place to live and in helping others when there is a need. People give back in many different ways, such as making monetary donations, giving their time to volunteer at a local school or event or fundraising for a cause.
When we asked our employees to tell us about what organizations they support, we were overwhelmed with their responses and all they have accomplished. We have highlighted a few of them, and the great causes, organizations, and charitable programs they support.
Dorian – American Red Cross
Dorian gives blood at the American Red Cross on a regular basis. After having close friends with cancer who needed blood transfusions and her own experience needing a blood transfusion, she realizes how fortunate we are to have access to a potential lifesaving blood supply.
Ron – Fairfax County Adult Detention Center, State Prisons and Federal Prisons
Ron, since the 1980s, has performed volunteer work in local jails and State and Federal prisons. Through these efforts, he has worked with serious and violent criminals. He volunteers on Tuesday and Thursday evenings at the Fairfax County Adult Detention Center.
Debbie –Fairfax County Animal Shelter
Debbie, through donor and volunteer support, provides food, supplies and more to help the shelter care for these loving animals. More than 5,000 pets, including cats, dogs, small mammals, reptiles and livestock, come to the Fairfax County Animal Shelter each year.
Jeff – Youth Mentor and Miriam’s Kitchen
Jeff volunteers as a mentor to two 5th grade boys at a local elementary school which has 70% reduced and free lunch. He gives them support, guidance and friendship. Jeff also volunteers at Miriam’s Kitchen in Washington DC. Previously, he volunteered weekly for about four years in the Case Management group working with individuals to ensure they had access to basic needs. He currently serves as a sub to the group as needed.
Dawne – Lorton Community Action Center (LCAC)
Dawne volunteers and has supported the Lorton Community Action Center (LCAC) for many years, through various initiatives including; the LCAC thrift store, warm coat drive, holiday food baskets, conducting food drives for their food pantry and the school backpacks for kids’ program.
Keith – MicroMentor and Umps Care
Keith is active in several organizations where he works as a mentor, consultant and board member. For ten years, he has focused on channeling his business skills and knowledge to help individuals (via kids and entrepreneurs) achieve new levels of personal success. While each of these organizations and others Keith has worked with are unique in their offerings, all of them have been very rewarding to him, regardless of the challenges.
Mike – SOME (So Other’s Might Eat)
Mike is a Corporate Advisory Board member who provides guidance and support to SOME’s management. He attends and sponsors their Annual Gala, occasionally serves meals at their dining hall, and participates in other initiatives to provide clothing and other goods to help the homeless.
Collectively, our employees support more than 40 charitable organizations. Many of them also take on active and leadership roles in their churches, local schools, children’s sports teams/associations and their communities on a regular basis. A sample list of some of the national charities our employees support include:
Whatever an individual chooses to do, no matter the size of the donation or the means by which they choose to volunteer – they in turn make a difference for the greater good of a community or cause. And, that is what giving back is really all about! Thank you, CC Pacers, for all you do!
On the first day of Job Hunting
my recruiter said to me:
update your resume quickly
On the second day of Job Hunting
my recruiter said to me:
Take two days on LinkedIn
and update your resume quickly
On the third day of Job Hunting
my recruiter said to me:
Post your resume on three job sites
Take two days on LinkedIn
and update your resume quickly
On the fourth day of Job Hunting
my recruiter said to me:
Research four preferred companies
Post your resume on three job sites
Take two days on LinkedIn
and update your resume quickly
On the fifth day of Job Hunting
my recruiter said to me:
Spend five days networking
Research four preferred companies
Post your resume on three job sites
Take two days on LinkedIn
and update your resume quickly
On the sixth day of Job Hunting
my recruiter said to me:
Schedule six meetings
Spend five days networking
Research four preferred companies
Post your resume on three job sites
Take two days on LinkedIn
and update your resume quickly
On the seventh day of Job Hunting
my recruiter said to me:
Here’s seven interviewing tips
Schedule six meetings
Spend five days networking
Research four preferred companies
Post your resume on three job sites
Take two days on LinkedIn
and update your resume quickly
On the eighth day of Job Hunting
my recruiter said to me:
Set up eight interviews
Here’s seven interviewing tips
Schedule six meetings
Spend five days networking
Research four preferred companies
Post your resume on three job sites
Take two days on LinkedIn
and update your resume quickly
On the ninth day of Job Hunting
my recruiter said to me:
Send nine thank you emails
Set up eight interviews
Here’s seven interviewing tips
Schedule six meetings
Spend five days networking
Research four preferred companies
Post your resume on three job sites
Take two days on LinkedIn
and update your resume quickly
On the tenth day of Job Hunting
my recruiter said to me:
You have ten offers, accept one already
Send nine thank you emails
Set up eight interviews
Here’s seven interviewing tips
Schedule six meetings
Spend five days networking
Research four preferred companies
Post your resume on three job sites
Take two days on LinkedIn
and update your resume quickly
On the eleventh day of Job Hunting
my recruiter said to me:
Only eleven days until your start date
You have ten offers, accept one already
Send nine thank you emails
Set up eight interviews
Here’s seven interviewing tips
Schedule six meetings
Spend five days networking
Research four preferred companies
Post your resume on three job sites
Take two days on LinkedIn
and update your resume quickly
On the twelfth day of Job Hunting
my recruiter said to me:
Enjoy twelve months of paychecks now
Only eleven days until your start date
You have ten offers, accept one already
Send nine thank you emails
Set up eight interviews
Here’s seven interviewing tips
Schedule six meetings
Spend five days networking
Research four preferred companies
Post your resume on three job sites
Take two days on LinkedIn
and update your resume quickly
Recently, we attended the SOME Gala at the National Building Museum in Washington, DC. SOME (So Others Might Eat) is an interfaith, community-based organization that was founded in 1970 by Father Horace McKenna, to help the poor and homeless of our nation’s capital. They work to meet the immediate daily needs of the people they serve with food, clothing, and health care.
Each year, SOME’s Corporate Advisory Board hosts the annual Harvest Gala to raise funds for SOME’s programs, which include their job training program, residential addiction treatment program and to support their affordable housing initiatives. The event is sponsored and supported by many businesses and individuals. To date, this annual event has raised over $10 million dollars to support their programs.
This year’s gala consisted of a silent auction, dinner and the presentation of the SOME McKenna Humanitarian award. This award is given each year to an individual(s) for their dedication and hard work on behalf of SOME.
The SOME community is looking forward to the 2018 grand opening of the Conway Center on Benning Road in DC. This center will include housing, job training, a medical clinic, offices and retail. In memory of Elizabeth Donohue, who was a compassionate advocate and benefactor of SOME, the Corporate Advisory Board named the family housing complex on Spring Road The Liz Donohue House.
Mike Gordon, President of CC Pace, has been on the Corporate Advisory Board of SOME for the last 19 years and CC Pace has been a proud supporter of this outstanding organization that has given so much to the community. Visit SOME.ORG to learn more about this organization and what you can do to get involved.
The Financial Services Team at CC Pace is very proud to announce the posting of a new white paper, which is based on the results of a recent industry survey. The senior consultants in our Mortgage Practice periodically reach out to a broad cross-section of the industry to gather direct input on the mood in the marketplace, current trends, pain points, technology innovations and more. The results from a survey we conducted in late summer can be found in “Mortgage Banking & Technology: Lenders’ Perspective”.
In this white paper, you will find lender input on a broad array of topics, including the competing priorities in the current market, the role of technology in competitive advantage, lender satisfaction with current technology and current progress toward a digital mortgage. One of the things we at CC Pace like to think distinguishes our survey results from others in the industry is our approach toward capturing a detailed, open dialog with our participating lenders. While the white paper certainly includes numerous charts quantifying the various positions the participants have on an array of topics, it also includes a wealth of insight in the form of direct quotes from lenders (albeit provided with anonymity, as per our agreement with the participants) on many issues. We hope you will agree that our open dialog approach makes our industry reports compelling reading, full of insight and perspective.
We hope you will enjoy our latest white paper and the view put forth by our participating lenders. Please share your thoughts with us, both on the paper itself and on topics you would like to see us cover in a future survey. And please let us know if you would like to be included in our next market survey, currently targeted for the first quarter of 2018.
Thoughts on Agile DC 2017
In early February of 2001, a small group of software developers published the Agile Manifesto. Its principles are now familiar to countless professionals. Over the years, Agile practices seem to have gained mainstream appeal. Today it is difficult to find a software developer, or even a manager who has never heard of Agile. Having been a software developer for over 15 years, to me, Agile methodologies appear to embody a very natural way of producing software, so in a lot of ways, Agile conferences produce a “preaching to the choir” effect as well. As I attended the Agile DC 2017 conference, I wanted to remove myself from the bubble and try to objectively take a pulse of the state of Agile today. I also wanted to learn about the challenges that Agile seems to continue to face in its adoption at the enterprise level.
Basic takeaways
As I listened to various speakers and held conversations with colleagues and even one of the presenters, it appears that today the main challenges of adopting Agile no longer deal specifically with software engineering. That generally makes sense, given the amount of literature, combined experience and continuous improvement software development teams have been able to produce as Agile has matured from a disruptive toddler into a young adult. The real struggle appears to be in adoption of Agile across other business units, not so much IT. Why is that? I believe the two main reasons for the struggle can be attributed to organizational culture, but most importantly lack of knowledge in relation to team dynamics and human psychology.
Culture
Agile seems to continue to clash with the way business units are organized. Some hierarchical structures may produce very siloed and stovepiped groups that have difficulty collaborating with one another. While this may appear as an insurmountable problem, there is at least one great example of how Agile organizations have addressed it. We can point to DevOps as a great strategy of integrating or streamlining traditionally separate IT units. Software development teams and IT Operations teams have traditionally existed in their respective silos, often functioning as completely separate units. There was a clear need of streamlining collaboration between the two to improve efficiency and increase throughput. As a result, DevOps continues on a successful path. In regards to other business units, “Marketing” may depend on “Legal” or “Product Development” may depend on “Compliance”. There may be a clear need to streamline collaboration between these business units. One of my favorite presentations at the conference was by Colleen Johnson entitled “End to End Kanban for the Whole Organization”. By creating a corporate Kanban board, separate business units were able to collaborate better and absorb change faster. One of the business unit leaders was able to see that there were unnecessary resources being allocated to supporting a product development effort that was dropped (into the “dropped” row on the board). Anecdotally, this realization occurred during a walk down the hall and a quick glance at the board.
Education
When it comes to software development, Agile appears to contain some key properties that make it a very logical and a natural fit within the practice. Perhaps its success stories in the software development community is what produced a perception that it applies specifically to software engineering and not to other groups within an organization. It seems to me that one of the main themes of the conference was to help educate professionals who possess an agnostic view related to the benefits of an Agile transformation. I believe that continuous education is critical to getting business unit leaders to embrace Agile at the enterprise level. Some properties of Agile and its related methodologies addresses some important aspects of human psychology. This is where the education seems to lack. There is much focus on improvement in efficiency and production of value, with little explanation of why these benefits are reaped. In simple terms, working in an Agile environment makes people happier. There are “softer” aspects that business leaders should consider when adopting Agile methodologies. Focus on incremental problem solving provides a higher level of satisfaction as work gets completed. This helps trigger a mechanism within the reward system of our brain. Continuous delivery helps improve morale as staff is able to associate their immediate efforts to the visible progress of their projects. Close collaboration and problem solving creates strong bonds between team members and fosters shared accountability. Perhaps a detailed discussion on team dynamics and psychology is a whole separate topic for another blog, but I feel these topics are important to managing the perception of the role of Agile at the enterprise level.
Final thoughts
It is important to note that enterprise-wide Agile transformations are taking place. For example, several speakers at the conference highlighted success stories at Capital One. It seems that enterprise-wide adoption is finally happening, albeit very incrementally, but perhaps that is the Agile way.
CC Pace realizes that it’s our people that really sets us apart from our competition. Keeping that in mind, we don’t take milestone work anniversaries lightly. We know our employees work hard and at CC Pace, we do our best to make sure they receive the celebration and recognition they deserve. It’s also a great time for us to reminisce about all the fun we have had over the years and share some good laughs!
CC Pace had fun recently celebrating the anniversaries of Debbie Shatz (30 Years) and Suzie Wheeler (15 years) at our quarterly company meeting. Debbie is a Director in our Financial Services practice and has performed in many roles over the years, including everything from a business analyst to strategic advisor and has consistently delivered valuable results to clients. Suzie is our Recruiting Manager and is responsible for handling both corporate and client recruiting needs, her ability to find and hire high quality personnel has had a great impact on our recruiting team’s success.
Both Debbie and Suzie were recognized by CC Pace President, Mike Gordon for their contributions and accomplishments during their time with CC Pace. Mike also presented each of them with a service award, and a specially selected, customized gag gift that highlighted each of them perfectly! In addition, Debbie was the recipient of one of Clay’s original songs – which is always a treat for the entire team!
So we say, “Cheers and Thank You” to Debbie and Suzie and we hope that you will each continue to grow with us for many years to come! Happy Anniversary!
Any business will tell you that retaining employees is important. The costs involved with the turnover of employees equals about a quarter of their annual pay. That takes into account the cost involved in: hiring, onboarding, the new hire’s learning curve and the ripple effects on the rest of the team. Every employer knows that the longer a person stays with a company, the more valuable and productive they become for that company.
At CC Pace, the retention rate for our staffing placements has been above 90% for the past 5 years. This article 4 Reasons why Employee Retention is Important (And 4 Reasons All Business Owners Should Use to reduce turnover) highlights why workforce retention is important, and strategies that can improve employee loyalty. A great deal of our success with our people is due to our commitment to provide our clients with the best candidates, based on this approach:
We work with our clients as a partner, finding the right fit by taking the time to truly understand their business and technology needs.
We are a consulting firm first – with full time business and technology experts available to help guide the qualification process and customized screening tools.
Most importantly, we make quality a priority over quantity. Knowing people means assessing their technical knowledge, their soft skills, their cultural profile, and everything in between.
Now that you have read about what we offer our clients and how we find the right fit for each position, you must be wondering what’s it really like to work for CC Pace? Let our consultants tell you firsthand about their experience working with CC Pace.
“The primary reason for choosing to work with CC Pace AGAIN is that they have top notch people who will ensure that you are a great fit for the openings, as well as making sure that your values align with theirs.” – Travis R., Consultant
“At the client site, CC Pace has always made sure I succeeded in doing my job which only shows how much they care about their people and their clients. I particularly appreciated how management was available to answer any questions I had while working on the client’s projects. Even though I worked with CC Pace as a consultant, I should note that I was treated equally as an employee.” – Namgyel D., Consultant
“I’ve been involved with CC Pace as an employee, contractor and customer for more than 22 of my nearly 35 years in the working world. I can honestly say that there is no better employer, contract vendor, or business partner with which I have had the pleasure to be associated. The employee-centric culture, strong business knowledge and technical expertise, and an ethical standard par none are why I have remained associated with them over the years. CC Pace provided me with the experience and opportunity needed to launch my career. Now, so many years later, I’ve come full circle, rejoining them and leveraging all that they helped provide.” – Paul H., Consultant
Looking to make a change in your career? Think about joining us and check out our latest job opportunities.
CC Pace employees came together to for a food packing event to support the efforts of Food for Others Power Pack Program. The Power Pack Program provides food packs for elementary school kids in Northern Virginia as a safety net to ensure that they have enough to eat over the weekend. This is a way to provide a healthy balanced meal for children who are either eating unbalanced meals, or perhaps adults who are skipping meals so their children can eat.
CC Pace purchased all the supplies needed for this event and our employees worked together to assemble the packages. This effort tested our “production line” skills and although it started out a little rocky, it ended great and we were able to get all the food packed and ready for distribution by Food for Others. In total we produced 288 meals, which will help to feed 48 children.
With Star Trek: Discovery’s television debut rapidly approaching, I can’t help but reflect on the many valuable lessons on project management I took away from the original series, Star Trek, and its successor, Star Trek: the Next Generation. Those two TV series counted on the strengths of their ships’ captains, James T. Kirk and Jean-Luc Picard, respectively, not only to help entertain viewers, but to provide fascinating insights into the characteristics of leadership. In so doing, the shows created timeless archetypes of starkly contrasting project management styles.
Kirk and Picard both had the title “Captain,” yet could not have been more different. In project terms, both series featured a Starship Captain operating as Project Manager, Project Sponsor and Project Governance all rolled into one. Yet despite common responsibilities, they were very different in how they carried them out, each with different strengths and weaknesses; one would often succeed in roles where the other would fail, and vice versa. Each episode was like a project, but on the show, thanks to their writers, each ship’s captain seemed to always get a “project” that they were well-suited for. But that only happens in real life if someone makes it happen, and most real-life projects don’t have writers working on the scripts.
Kirk and Picard were polar opposites in management style in many ways, and most people involved with project execution have common traits with each. Suppose you are like one of them – are you a Kirk or a Picard? – what should you do to maximize your strengths and minimize your weaknesses? Suppose one is on your project – how do you ensure they are put to their best use? How should you be using them and what role should they play? What would they be good at and not so good at?
To get down to basics, the biggest difference between the two is Kirk is “hands on” versus Picard is “hands off.”
Kirk is clever and energetic. Because he is “hands on,” he is always part of the “away team” – the group of people who “beam down” to the whatever this week’s show is. The senior management here is typically the project team. When additional work was found, he did it himself, or with the existing team.
Picard is visionary and a delegator. He is more of a leader than a manager. He set objectives, made decisions and, obviously “hands off,” told Number One to “make it so.” Number One led the project team; Picard rarely went himself.
The best use of a Kirk is as a project manager with delegated authority on a short-term project with a fixed deadline, like a due diligence effort requiring the current situation to be assessed and a longer-term plan of action defined to address deficiencies. Kirk’s style and authority allows the team to move quickly; if additional tasks appear, Kirk will summon enough energy to get himself and the team through it. When decisions need to be made, he makes them. He will shine. But on a long-term project, if there is additional scope discovered (and there always is), Kirk will become a martyr, skipping vacations and asking his team to do the same. He will fail at some of his primary tasks – staffing the project properly, as example – and will inadvertently overestimate the current state of the project to his stakeholders, and underestimate the risks. Here again, it only works on TV.
The best use of Picard is as a project sponsor – he has the vision and needs you to implement it. The trick will be keeping him involved. On a short-term project he wouldn’t be your first choice for a PM – unless it was a subject that he cared deeply about – because he might delegate without being very involved.
If Number One got into trouble, but didn’t know it (e.g., the boiling frog parable: as the water heats up, the frog never notices until it is too late), Picard wouldn’t be providing enough oversight to know it either. Or, if his insight was needed, then there might be a delay while waiting for him to decide. On a long-term project, the project will need strong oversight to monitor progress and ensure engagement. That way Picard can keep the team focused on the right things. Picard could also be a PM on a long-term project like a process transformation. If there was a new requirement, it would never occur to him to try and do it himself – he would go to the sponsor to explain the tradeoffs of doing or skipping the new requirement, and get the right additional staff to do it. His management style is great for delegation and building a team, as well as developing the people on that team.
I know that both Kirk and Picard have their fans, and their project management skills both work on TV and in movies – but because there they always the type of project to work on that suits them, as the writer made it be so. In real life you need to be more flexible in how you use them, and apply the right one, or at least the right traits, to meet your business objective. Understanding this, and acting accordingly, may be as close to having a script writer for our projects as most of us will ever get.
Boy this summer flew by quickly! CC Pace’s summer intern, Niels, enjoyed his last day here in the CC Pace office on Friday, August 18th. Niels made the rounds, said his final farewells, and then he was off, all set to return to The University of Maryland, Baltimore County, for his last hurrah. Niels is entering his senior year at UMBC, and we here at CC Pace wish him all the best. We will miss him.
Niels left a solid impression in a short amount of time here at CC Pace. In a matter of 10 weeks, Niels interacted with and was able to enhance several internal processes for virtually all of CC Pace’s internal departments including Staffing, Recruiting, IT, Accounting and Financial Services (AFA), Sales and Marketing. On his last day, I walked Niels around the office and as he was thanked by many of the individuals he worked with, there were even a few hugs thrown around. Many folks also expressed wishes that Niels’ and our paths will hopefully soon cross again. In short, Niels made a very solid impression on a large group of my colleagues in a relatively short amount of time.
Back in June I gladly accepted the challenge of filling Niels’ ‘mentor’ role as he embarked on his internship. I’d like to think I did an admirable job, which I hope Niels will prove many times over in the years to come as he advances his way up the corporate ladder. As our summer internship program came to a close, I couldn’t help reminiscing back to my days as a corporate intern more than 20 years ago. Our situations were similar; I also interned during the spring/summer semesters of my junior year at Penn State University, with the assurance of knowing I had one more year of college remaining before I entered the ‘real world’. My internship was only a taste of the ‘corporate world’ and what was in store for me, and I still had one more year to learn and figure things out (and of course, one more year of fun in the Penn State football student section – priorities, priorities…)
Penn State’s Business School has a fantastic internship program, and I was very fortunate to obtain an internship at General Electric’s (GE) Corporate Telecommunications office in Princeton, NJ. My role as an intern at GE was providing support to the senior staff in the design and implementation of voice, data and video-conferencing services for GE businesses worldwide. Needless to say, this was both a challenging and rewarding experience for a 21-year-old college student, participating in the implementation of GE’s groundbreaking Global Telecommunications Network during the early years of the internet, among other things.
As I reminisced back to my eight months at GE, I couldn’t help but notice the similarities between my internship and a few of the ‘lessons learned’ I took away from my experience 20+ years ago, and how they compared or contrasted to my recent observations and feedback I provided to Niels as his mentor. Of course, there are pronounced differences – after all, many things have changed in the last 20 years – the technology we use every day is clearly the biggest distinction. I would be remiss not to also mention the obvious generation gap – I am a proud ‘Gen X’er’, raised on Atari and MTV, while Niels is a proud Millennial, raised on the Internet and smartphones. We actually had a lot of fun joking about the whole ‘generation gap thing’ and I’m sure we both learned a lot about each other’s demographic group. Niels wasn’t the only person who learned something new over the summer – I learned quite a bit myself.
In summary, my reminiscing back to the late 90’s certainly helped make my daily music choices easier for a few weeks this summer led to the vision for this blog post. I thought it would be interesting to list a few notable experiences and lessons I learned as an intern at GE, 20 odd years ago, along with how my experiences compared or contrasted with what I observed in the last 10 weeks working side-by-side with our intern, Niels. These observations are based on my role as his mentor, and were provided as feedback to Niels in his summary review, and they are in no particular order.
Have you similarly had the opportunity to engage in both roles within the intern/mentor relationship as I have? Maybe your example isn’t separated by 20 years, but several years? Perhaps you’ve only had the chance to fulfill one of these roles in your career and would love the opportunity to experience the other? In any case, see if you recognize some of the lessons you may have learned in the past and how they present themselves today. I think you’ll be amazed at how even though ‘the more things change, the more they stay the same’.
Each year the Fairfax Animal Shelter helps four to five thousand animals by providing a safe environment and adoption services. CC Pace employees and friends volunteered here last week to support this great organization and did a great job of cleaning the facility, folding towels, and organizing supplies.
While our employees did not interact with the animals, they were able to walk through the facility and see the dogs, cats, and other smaller furry and feathered creatures and their environment. You can see by the smiles in the pictures of our people, that this was a very rewarding event for everyone!
Thanks to Deb Young, our account manager, for coordinating with Debbie Shatz, a Director in our Financial Services practice, to set up this event. Debbie is a long-time volunteer at the shelter and she organized and directed our activities for the evening. We would like to give a special shout-out to Tracy Gordon, Bobby Pantall, Jason Kellenbenz, and everyone else who donated the vast amount of toys and essentials needed by the shelter. They were well received and very much appreciated!
Want to get involved? Contact the Fairfax Animal Shelter, they can always use volunteers!
PowerApps Basics
PowerApps is one of the most recent additions to the Microsoft Office suite of products. PowerApps has been marketed as “programming for non-programmers”, but make no mistake; the seamless interconnectivity PowerApps has with other software products allows it to be leveraged in highly complex enterprise applications. PowerApps basic is included in an Office 365 License, but for additional features and advanced data connections, a plan must be purchased. When I was brought on to CC Pace as an intern to assist with organizational change regarding SharePoint, I assumed that the old way of using SharePoint Designer and InfoPath would be the framework I would be working with. However, as I began to learn more about PowerApps and CC Pace’s specific organizational structure and needs, I realized that it was essential to work with a framework geared towards the future.
Solutions with PowerApps
While Big Data and data warehousing become common practices, data analytics and organized data representation become more and more valuable. On the small to medium organizational scale, bringing together scattered data which is stored in a wealth of different applied business practices and software options has been extremely difficult. This one of the areas where PowerApps can create immense value for your organization. Rather than forcing an extreme and expensive organizational change where everyone submits expense reports, recruitment forms, and software documentation to a brand new custom database management system, PowerApps can be used to pull data from its varying locations and organize it.
PowerApps is an excellent solution for data entry applications, and this is the primary domain I’ve been working in. A properly designed PowerApp allows the end user to easily manipulate entries from all sorts of different database management systems. Create, Read, Update, Delete (CRUD) applications have been around and necessary for a long time, and PowerApps makes it easy to create these types of applications. Input validation and automated checks can even help to prevent mistakes and improve productivity. If your organization is constantly filling out their purchase orders with incorrectly calculated sales tax, a non-existent department code, or forgetting to add any number of fields, PowerApps allows some of those mistakes to be caught extremely early.
Integration with Flow (the upgraded version of SharePoint designer WorkFlows), allows for even greater flexibility using PowerApps. An approval email can be created to ensure to prevent mistakes from being entered into a database management system, push notifications can be created when PowerApps actions are taken, the possibilities are (almost) endless.
Pros and Cons
There are both advantages and disadvantages to leveraging software in an enterprise solution that is still under active development. One of the disadvantages is that many of the features that a user might expect to be included aren’t possible yet. While Flow integration with PowerApps is quite powerful, it is missing several key features, such as an ability to attach a document directly from PowerApps, or to write data over multiple records at a time (i.e. add multiple rows to a SQL database). Additionally, I would not assume that PowerApps is an extremely simple, programming free solution to business apps. Knowledge of the different data types as well as the use of functions gives PowerApps a steep learning curve. While you may not be writing any plaintext code, other than HTML, PowerApps still requires a good amount of knowledge of technology and programming concepts.
The main advantage to PowerApps being new software is just that; it’s brand new software. You may have heard that PowerApps is currently on track to replace, at least partially, the now shelved InfoPath project. InfoPath may continue to work until 2026, but without any new updates to the program, it may become obsolete on newer environments well before that. Here at CC Pace, we focus on innovation and investing in the solutions of tomorrow, and using PowerApps internally rather than creating a soon non-supported InfoPath framework was the right choice.
Author Bio As a programmer and cybersecurity enthusiast, creating pieces of enterprise systems is something I never knew I would be so interested in. I’m Niels Verhoeven, a summer IT Intern at CC Pace Systems. I study Information Systems with a focus on Cybersecurity Informatics at University of Maryland, Baltimore County. My experiences at CC Pace and my programming background have given me quite a bit of insight into how users, systems, and business can fit together, improving productivity and quality of work.
Previously, in Part 1 of this blog series, we discussed how U.S. News and World Report stated that two-thirds of the candidates employees refer get hired and how companies benefit by hiring those employee referrals. Today, we want to address how to build your own personal network.
By creating a network, you expose yourself to unlimited opportunities to have doors opened for you when searching for a new position. And, in turn, you may be able to open some doors for others. So, how do you get started?
It’s easy: start by getting social! Create your profile in LinkedIn and/or Facebook. Depending on your area of expertise, a Twitter or Pinterest account may also be beneficial. Now start connecting with everyone you know! Here is a list of Top 10 Places to Find People to Grow Your Network:
Associates in your current and past places of employment
Customers/Clients (both current and past)
Friends, family, friends of friends, and neighbors
Professional organizations or associations
The Alumni program at your alma mater
Do you have children? If so, reach out to other parents, teachers, coaches, instructors, and scout leaders
Fellow members of any clubs, organizations, church and community groups
Get involved with your civic association or homeowners association
Do you have a gym membership? Get to know some of your fellow gym members!
Include those whose services you use, your hairstylist, mail carrier, doctor, house cleaner, pet sitter, baby sitter, repairman, etc. They all have built their businesses on referrals so they are a great resource.
The network you build will give you the ability to use these contacts to help you find your next position. Now when you apply for a new job you will use your network for a connection to get your foot in the door with a referral – remember the saying “it’s all about who you know”!
At CC Pace our Referral Program is open to everyone. It’s simple: refer someone to us for a position and, if they get hired, you get a referral bonu$! So take a minute, and check out our job postings and refer away! While building a network can seem like a lot of work, in the end the opportunities and professional gains that come your way will be well worth it!
CC Pace recognized four employees who were celebrating their 15th and 35th anniversaries at our quarterly meeting earlier this month. CC Pace President, Mike Gordon, had the pleasure of recognizing Bill Lehman (35 years), Laura Campbell (15 years), Bobby Pantall (15 years) and Deb Young (15 years) for their service. Each were recognized for their dedication, contributions and hard work, and were presented with a service award and the always hilarious CC Pace gag gift!
In reflecting on these significant milestones, we decided to do a little research. According to the Bureau of Labor Statistics the average tenure for employees with their current employers in the United States is 4.2 years. At CC Pace our employees’ average tenure is 12.7 years, that’s 3 times the national average!
So, why is the average tenure at CC Pace so high? Well, we decided that we would ask some of the service award recipients what it is that makes CC Pace such a desirable place to work. They agreed on several common elements, which include:
The dedicated people they work with
The supportive environment received from their leadership
The work/life balance offered by CC Pace
In addition, Deb appreciates the feeling that she is “making a contribution”, Bobby highlighted “the interesting work” he gets to be part of, while Laura pointed out “the variety of opportunities that employees are given to help the organization grow”.
Or, could the reason the tenure is high be something else, like those world-famous gag gifts given on milestone anniversaries? The free bagels and donuts? The happy hours? The company parties? We may never really know the exact answer – but, it’s apparent that all these things together have created a unique culture where employees choose to stay and succeed in for many years.
Whatever the reason, we are grateful for these employees. Congratulations and thank you!
Why user stories don’t always make sense:
I am doing a lot of work with business units adopting Scrum or Kanban. As I explain to them, writing a user story in the correct format may not add any value to them. User Stories date back to Extreme Programming (XP). In the first part of the story “as a _____”, the blank is filled in with the user. As Product Owners identify users, they should be creating Personas that identify key user attributes. A millennial user will have different usage of an application than a retiree. These personas help the developer think about the user as they design how they will implement each user story. When a business unit is simply trying to get transparency about the work they are doing, their stories may be more of the “spike” or “technical” story variation. My question to these teams is can you identify the person receiving value when implementing the story? They think about this and sometimes think it is just their manager, or the company. The most common mistake is that the person doing the work is writing the story with their job title in the first blank; or getting a story with “As a Product Owner”. When using Scrum or any other Agile method for non-software work, I believe going through the effort of writing the story in User Story format As a ______, I want _______, So that______, just adds extra overhead, and no true value to the person doing the work. Instead, I recommend they save themselves that overhead and simply write “Create ____” or “Do _____”. The real value is in having good Acceptance Criteria. For example, if I want to have use a backlog for chores at home a User Story might look like:
As a Parent
I want the dishes done
So that the kitchen will be clean
Acceptance Criteria:
1 – No dishes remain lying around the house
2 – All dishes are in the dishwasher
3 – All kitchen surfaces are clean
Well this is great, I could just as easily write “Do the dishes” as my story keeping the acceptance criteria, so it is clear what is required.
For me, working in an Agile manner means reducing waste while increasing value. If you aren’t creating an application with users, going the distance to write a complete User Story is just waste. In Scrum there are four things in your product backlog, take advantage of that mindset. Skip the formality of the User Story.
I’m in the process of reading a book on Agile database warehouse design titled, appropriately enough, Agile Data Warehouse Design and by Lawrence Corr.
While Agile methodologies have been around for some time – going on two decades – they haven’t permeated all aspects of software design and development at the same pace. It’s only in recent years that Agile has been applied to data warehouse design in any significant way.
I’m sure many Agile consultants have worked on projects in the past where they were asked to come up with a complete design up-front. That’s true with data warehouse projects too where a client’s database team wanted the entire schema designed up-front – even before the requirements for the reports the data warehouse would be supporting were identified. What would appear to be driving the design was not the business and their report priorities, but the database team and their desire to have a complete data model.
While Agile Data Warehouse Design introduces some new methods, it emphasizes a common-sense approach that is present in all Agile methodologies. In this case, build the data warehouse or data mart one piece at a time. Instead of thinking of the data warehouse as one big star schema, think of it as a collection of smaller star schemas – each one consisting of a fact table and its supporting dimension tables.
The book covers the basics of data warehouse design including an overview of fact tables, dimension tables, how to model each and as mentioned, star schemas. The book stresses the 7-Ws when designing a data warehouse – who, what, where, when, why, how and how many. These are the questions to ask when talking to business to come up with an appropriate design. “How many” is applicable for the fact tables, while the other questions apply to dimension table design.
Agile Data Warehouse Design stresses collaboration with the business stakeholders, keeping them fully engaged so that they feel like they are not just users, but owners of the data. Agile Data Warehouse Design focuses on modeling the business processes that the business owners want to measure, not the reports to be produced or the data to be collected.
I still have a way to go before I’ve finished the book and then applied what I’ve learned, but so far, it’s been a worthwhile learning experience.
Sure, the office seems nice, the finishes are modern, fresh and bright, but day-to-day what goes on within the walls of the office environment are what really matters. When you are seeking a new position you need to remember that not only are they interviewing you, but you are interviewing them as well.
Here are some key question to keep in mind: What is the ideal company culture for you? Do you succeed in a more casual or formal business setting? Do you like a hands-on leadership approach? Does this company share the same values you do in making sure things are done correctly versus just getting the job done?
How to Determine If a Company Is a Good Fit for You gives a great perspective on important factors you should consider before you sign your next offer letter. Remember—the interview process is just as important for you as it is for the hiring company.
CC Pace would like to introduce you to Deepti Agarwal a Senior Technical Recruiter who has been part of our Staffing team since 2013. Prior to CC Pace, Deepti worked as a full life cycle, technical recruiter supporting both commercial and federal government clients. In addition, she worked with the account managers to strategize in acquiring new and building existing accounts.
What attracted you to CC Pace?
I first learned of CC Pace through my husband who had been working with the company. He spoke highly of CC Pace and felt they never compromised with the quality of candidates submitted to them. He had known them to be very fair when it came to all aspects of the recruiting process and in all, CC Pace was a very reputable organization to work with.
When the time came for me to a make a move to a new recruiting position, I immediately thought of CC Pace. The interview process went very well and I knew that it was the perfect fit as I learned more about the CC Pace clients and the recruiting process they followed. It reflected that the recruiting group worked as a team and had a very strong value-based system. The environment was friendly and welcoming from the very beginning.
What is the biggest challenge in your current role?
There are actually two challenges. The first one is that we are in a very demanding and competitive marketplace, there is a lot of competition that we are up against every day from both a client and a resource perspective. The second is closing candidates with multiple offers at the end of the recruiting process. This process can take some time to complete as candidates are often interviewing with several companies.
How would you describe CC Pace’s culture?
First and foremost, CC Pace has a very value-based culture and provides a high quality of service to all our clients and candidates. In Staffing, we have a strong team environment and our Staffing group’s management truly respects our opinions and supports us. CC Pace also offers me the perfect work life balance, having flexible working hours makes things much easier for me and my family.
During your time here at CC Pace, can you share with us something you have learned?
Because of the values we uphold we never compromise on the quality of our service.
What do you like to do outside of CC Pace?
I love to spend time with my daughters. I cherish our time together, we enjoy taking dance classes together and of course, they are always up for a shopping trip!
What is your favorite vacation spot and why?
Cancun! My family and I went there last year and it was absolutely gorgeous! It was so relaxing and peaceful and there were so many activities and watersports available to participate in – my favorite was snorkeling by a reef, it was just beautiful.
Who inspires you and why?
My father – he is a doctor a heart specialist and he is truly my inspiration. His strong work ethic and sincerity taught me the meaning of what being a hard working individual was all about.
Is your business undergoing an Agile Transformation? Are you wondering how DevOps fits into that transformation and what a DevOps roadmap looks like?
Check out a webinar we offered recently, and send us any questions you might have!
A startling statistic that often gets overlooked is that 70% of projects world-wide fail. Each year, more than one trillion dollars are lost to failed projects. Most importantly, statistics show that these failures are frequently not the result of a lack of technical, hardware or software capabilities. Instead, these failures are typically due to a lack of adequate attention being paid to program management.
After seventeen years working in program management―implementing enterprise business strategies and technology solutions―I continue to be surprised by business leaders who misunderstand the differences between project management and program management, or simply think them to be two terms that refer to the same thing. Fact is, program management and project management are distinct but complementary disciplines, each equally important to ensuring the success of any large-scale initiative.
Let’s take just a minute to level-set the roles of both. Project management is responsible for managing the delivery of a ‘singular’ project, one that has defined start and end dates and is accompanied by a schedule with a pre-defined set of tasks that must be completed to ensure successful delivery. Project management is focused on ‘output’. Program management, on the other hand, takes a more holistic approach to leading and coordinating a ‘group’ of related projects to ensure successful business alignment and organizational end-to-end execution. A program doesn’t always have start and end dates, a pre-defined schedule or tasks to define delivery. Program management is primarily responsible for driving specific ‘outcomes’, such as ensuring the targeted ROI of an initiative is achieved. Put another way, program management is basically the ‘insurance policy’ of a project, the discipline needed to make sure all the right things are done to ensure the likelihood of success.
One analogy I often use to help differentiate the roles of a program manager and project manager is that of a restaurant. The executive chef (project manager) works within a defined budget, makes certain the kitchen is adequality staffed and creates the menu. The executive chef will provide defined tasks, processes, tools and strategies that ensure efficient and consistent delivery of meals. The meals are a tangible delivery (output). Overseeing the chef, the restaurant owner (program manager) will provide the executive chef with a budget to work from and will closely monitor the output of the kitchen. The owner will make sure each delivery and support role is adequately staffed, trained and paid (e.g., wait staff, hostess desk, dishwasher, bussers and bartender). The owner will also make certain all the details like music and lighting are in place and establish an appropriate ambiance. The owner will make sure the right tools are in place for flawless execution (such as utensils, glasses, napkins, water pitchers, pens and computers), while making sure expected standards and key performance indicators are being met to achieve overall profitability targets and a great end-to-end customer experience (outcomes). The restaurant owner’s primary responsibility is to focus on merging the tangibles with the intangibles to support successful business strategy execution.
When it comes to mortgage banking, an industry that’s known more than its fair share of failed implementations, it is critical that we start giving program management a greater priority, and ensuring that those commissioned to perform the role are equipped with the requisite skills and tools. Whether it’s adding a new imaging platform, bolting on new CRM or POS technology, or something as expansive as replacing an LOS, every enterprise initiative requires a project manager to be leading the implementation effort and a program manager focused on change management and roll-out. Consider the addition of an end-to-end imaging system. A program manager’s tool box should include strategies and frameworks to effectively manage the roadmap for each critical impact point. This would include things like training, updating policies and procedures, executing an internal change management strategy, synchronizing marketing communications, and updating key performance indicators. In some instances, the project may require staff analysis, skills assessments, compensation analysis and adjustments, or even right-sizing of the organization. All of these are key components of the program manager’s toolbox, and not generally covered within the role of a project manager.
Bringing this dialog back full-circle, program management helps reduce project failure rates by maintaining a holistic approach to guiding an organization’s successful adoption of the impending change, leaving the nuts and bolts of build-out in the hands of project management. By addressing the myriad of intangibles required to orchestrate successful adoption and acceptance of change by an organization’s personnel, program management also helps ensure that business strategies and projects remain in full alignment and ROI objectives are achievable. Preparing management and staff for the impending changes defuses fears that can send adoption off the rails and eases the transitions and realignment of resources and roles that often accompany larger initiatives.
In closing, it’s not surprising to find the lines between project and program management will easily get blurred. Our experience is that it is often difficult to identify a really good project manager that is proven capable of undertaking a large-scale effort, but even more so to find someone truly adept at managing all the moving parts of the program. This difficulty is even more apparent in organizations where undertaking significant projects is a relatively rare occurrence and these skills are simply not found among existing staff. While it may seem adequate to budget for a singular project manager and hope that the program elements will be attended, managed and executed, unfortunately, “hope” is not a viable strategy when it comes to business-critical initiatives. The assignment of a skilled program manager, whether sourced internally or externally, will ultimately prove to serve as an effective insurance policy to your project investment. In an industry where failure cannot be afforded, it’s time to stop gambling on project execution and begin implementing program management
Many people ask, what is the distinction between an Agile adoption and an Agile transformation? The former being the adoption of an Agile method and tools, and the latter encompassing those plus the people, culture and mindset shift that must accompany the adoption for an organization to fully realize the benefit.
The real difference between adoption and transformation is that adoption fails and transformation sticks. You don’t really choose one over the other – people that fail to see the difference often do the adoption because they don’t realize that culture is what makes it really stick. Most organizations start with the adoption of a method at the team level within IT. Some will also covey the message to ‘do Agile’ from the top. However, this type of adoption rarely sticks. Middle management is lost in the shuffle, often just waiting out the change and expecting it to fail. The focus is on processes and tools – not people and interactions. The mindset of transparency, adaption and continuous improvement is misplaced in favor of mechanics and metrics.
A true transformation requires the organization to think and ‘be Agile’. It requires the organization to look at their people, organization and culture, as well as their process and tools. An organization will move through stages improving and absorbing changes in these areas. Typically, an organization will begin with a pilot with one or more teams. This allows the organization to best see how Agile will affect the current process and roles, and help to uncover gaps and potential areas of conflict, such as, central versus decentralized control.
It takes time to move through all the stages that are mapped out for the process, and much depends on the attitude and behaviors of leadership. Does leadership model the behavior they seek in others? Do they look to break down barriers to value delivery? Do they reward the team and system success rather than individual or functional success? Another important factor is that the organization knows what it is driving towards. This vision and accompanying goals are what will drive the pilot and future transformation activities. This alignment is the first step. As CC Pace continues to work with companies through this process we see the positive effects gained throughout each organization.
If you are interested in learning more about Agile Transformations, join us on Tuesday, June 13, for a free webinar on the topic! Click here to register.
As a manager or leader, some of the biggest mistakes you can make are not sharing your vision, holding on to control, not letting your team grow as professionals and simply not saying thank you enough.
In this article by Dave Ramsey, he has a list of 4 Ways to Empower Your Team. It’s a quick read with a solid message:
Share Your Vision
Stop Micromanaging
Enhance Their Skills
Brag on Them
Yes, that’s a short list, but each item has a significant impact. Employees do not feel connected when they don’t know where the company is planning to go, things to do not move forward quickly and time can be wasted when they are not able to make decisions on their own. Your team needs the ability to grow through training and mentoring, and they need to feel appreciated so that they know that you are aware of their efforts.
Start today, pick one task and give your team the ability to make a decision. It will make your employees feel valued and may increase morale in your workplace. So, just just let it go and see what happens. You may be surprised and find that your job just got less stressful!
Pulling from our considerable experience with the unique aspects of implementing a mortgage loan origination system (LOS), CC Pace has recently published a new white paper on the topic, “The Art of Planning an LOS Implementation Budget.” The information covered in the white paper, while essentially specific to LOS implementations, is broadly applicable for any product implementation project.
Best practices indicate that thorough project planning is the most critical step for a successful system implementation, and we concur wholeheartedly. One of the key activities that should be performed during the planning phase is the development of a detailed implementation budget. The budget is particularly important when establishing expectations with Senior Management and gaining support for the effort. Too often, planners fail to consider the costs beyond those of the software, vendor configuration and any vendor-provided customizations when in fact the all-in cost of an implementation includes much more.
We hope that readers see the importance of taking a more comprehensive perspective when planning their next project and we welcome your feedback. What other line items do you include in your budget preparation process?
In our personal and professional lives when we meet new people, even if just for a minute, they walk away with that first impression of us. That impression good or bad will stay with them. That is why it is essential to keep in mind some tips on making a good first impression, especially when going for that all important job interview. This blog 8 Ways to Make a Good First Impression reminds us of how others see us at those first moments upon meeting us.
As a continuation of our blog series on system selection, it’s time to discuss helpful tips to facilitate a successful product demonstration. The organization and management of the entire process requires upfront preparation. If you drive the process, your demo evaluations will be far more effective.
Demonstrations are one of the most critical components of the software selection process. Seeing a system in action can be a great learning experience. But not all demos are created equal. Let’s talk about how you can level the playing field. To make the most of everyone’s time, CC Pace recommends the following best practices for product evaluations.
Tip One – Keep your process manageable by evaluating no more than five systems. If you evaluate too many vendors, it becomes difficult to drill down deep enough into each offering. You will inevitably suffer from memory loss and start asking questions like, “which system was it that had that cool fee functionality that would be really helpful?”
Tip Two – For each software vendor, set a well thought out date and time for the on-site demo. Depending on your team’s travel schedule, try to space out the demos a few days apart so that you have time to prepare and properly analyze between sessions.
Tip Three – Logistics play a big role in understanding how a system looks and functions, so do your part to help your vendors present well. Whenever possible, arrange for a high-quality projector or large HD screen for the attendees in the room. Hard-wired internet connections are always better. There’s nothing worse than being told, “the screen issues are because of a resolution problem” or “it’s running slow because the air card only has one bar.” Providing these two items can easily remove doubts about external factors causing appearance and performance issues.
Tip Four – Involve the right people from your organization. It’s important to have executive sponsorship as well as hands-on managers involved to assess the software modules. This is also the best opportunity to get “buy-in” from all parts of your organization.
Tip Five – Be sure to head into these demonstrations knowing your key requirements. Visualize it as a day in the life of a loan and follow a natural progression from initial lead into funding. Jumping around causes confusion and can be difficult on the vendor.
Build a list of requirements based on the bulk of your business. Asking to see how the software handles the most complicated scenarios can send the demo down needless paths. No one wants to watch a sales person jump through a bunch of unnecessary hoops for a low-volume loan product.
If you highlight which functional capabilities are most important to your organization, the vendors can spend more time demonstrating those capabilities in their software. Communicate how you think their software can help. But be careful not to justify why something is done a certain way today, but rather focus on how it should be done in the future.
Tip Six – The easiest way to take control of the demo process is to draft demo scripts for your vendors. Start by identifying the ‘must-have’ processes that the software should automate. Don’t worry about seeing everything during this demo. Set the expectation that if the demo goes well, the vendor will likely be called back again for a deeper dive. Provide a brief description of each process and send it to the vendor participants so they can show how their software automates each process. The best vendor partners will have innovative ways to automate your processes, so give them a chance to show their approach.
As you watch the demos, keep track of how many screens are navigated to accomplish a specific task. The fewer clicks and screens, the better. Third-party integrations can significantly help with the data collection and approval process. Always have an open mind regarding different ways to accomplish tasks and don’t expect your new software to look or act just like your legacy system.
Simple scorecards should be completed immediately following each demonstration. This will make it easier to remember what you liked and disliked and prove invaluable when comparing all the systems side-by-side when your demos are complete.
One final suggestion: always request copies of the presentations. Not only will this help you remember what each system offers, it’s useful when the time comes to create presentations for senior management.
photo credit: http://www.freepik.com/free-vector/business-presentation_792712.htm Designed by Freepik
In December, I wrote a blog about the role of Scrum Master as a Facilitator, see it here. In today’s post I want to go into a bit more detail about the skill needed to be a good Facilitator. Many of you may be thinking that facilitating is easy, you just stand in front of the room and lead meetings. In fact, facilitators aren’t always in front of the audience, and it takes a lot of practice and skills to be a really good facilitator.
So what skills do you need to be a good facilitator?
Be Present – understand how your body language, voice intonation and tempo impact the team.
Do you have something distracting you? Check it at the door.
Do you have hot buttons that the team pushes? Address them in your own time, don’t let them be activated in the session.
Have a tool bag of techniques for driving to outcomes.
How do you get teams to coalesce on a decision?
How do you identify root causes?
How do you ensure everyone feels heard?
Address team dysfunctions – understand what is going on for the attendees.
Humans show how they are feeling about the process in many ways, so facilitators need a large tool bag to deal with personalities in the team like:
The Whisperer
The Loudmouth
The Know-it-all
The Silent One
The Head Shaker
The Doubter
Have a good “Wrap Up”
Ensure action items are assigned
Ensure decisions are recorded
Track and follow-up on parking lot items
All of these skills can be learned and practiced to make Scrum Master better facilitators. Use of facilitator skills extends beyond Scrum Events to everything the Scrum Master does.
To develop your skills and learn how to be a good facilitator, check out our ICAgile Team Facilitator certified class being held May 9-10 in Fairfax, VA.
In this class you learn and practice facilitating through a number of interactive exercises that relate to facilitating anywhere as well as to specific Scrum Events.
I have enjoyed using analogies between baseball and software development in a few of my previous blog entries, so with Major League Baseball’s season underway, there’s no better time than now to write another baseball-oriented blog entry. But don’t fret, non-baseball fans, because this message, like so many others, applies to both life AND baseball.
In recent years, I’ve observed many software development teams engaged in long-term, multiple-release software development projects. I would classify these as projects incorporating stable, unchanging teams, spanning a year or more and challenged with navigating through fluctuations of tension – followed by calm – which usually accompany projects with multiple production releases.
An interesting and alarming behavioral tendency seems to have emerged – or more likely, I’m only now noticing it – with enduring, static teams working together on projects or applications spanning multiple releases. This behavior isn’t an obvious, tangible issue like a team member missing meetings. Rather, it’s a human behavioral trait that seemingly emerges unnoticed and isn’t uncovered – if it’s even uncovered at all – until it’s usually too late, after the damage has been done.
What is this negative tendency you may ask? And what in the world does this have to do with baseball? Well, it can be defined with many words or explanations, but for this blog, we’re using one word: LOLLYGAGGER. Trust me, as you will see, you don’t want to be called a lollygagger, as it’s definitely not a compliment or a term of endearment. And you certainly don’t want to be developing software with or managing a team full of lollygaggers.
thefreedictionary.com defines the verb ‘lollygag’ as follows: To waste time by puttering aimlessly; dawdle. This simple definition does not do proper justice to this word.
Side note: It would also be prudent to mention here that this behavior doesn’t seem to manifest itself on greenfield projects, or short-term engagements with newly-formed teams for obvious reasons – arrangements which usually permeate high-energy and team enthusiasm during the early ‘forming’ stages of team development (see Tuckman’s Stages of Group Development). This would make sense as a lack of enthusiasm is usually not a characteristic of newly-formed teams.
So, this odd linkage came to mind when the movie Bull Durham appeared on television a few nights ago, which – aside from providing the vision for this blog entry – is one of my all-time favorites. Critically acclaimed as one of the greatest American sports movies of all time, Bull Durham is a must-see for any baseball enthusiast. The movie is based on one person’s experiences in minor-league baseball and depicts players and fans of the Durham Bulls, a minor-league baseball team residing in Durham, North Carolina.
One gains a TRUE SENSE of how lollygagging can hurt any team watching one of my favorite scenes in the movie which casts “Crash” Davis, the wise, veteran catcher and the Bulls’ manager, known as “Skip” (of course). The Bulls are playing awful baseball, mired in a long losing streak, and the manager has run out of patience and ideas. Which takes us to the scene inside the Bulls locker room after yet another painful loss:
Skip: “I don’t know what to do with these guys. I beg… I plead… I try and be a nice guy… I’m a nice guy.”
Crash: “Scare ‘em.”
Skip: “Huh?”
Crash: “Scare ‘em. They’re kids, scare ‘em. That’s what I’d do…”
After a chuckle, and now armed with this ingenious managerial advice, “Skip” proceeds to forcefully assemble his unsuspecting group of apathetic ballplayers into the shower area, throwing an entire rack of baseball bats into the shower after them, which certainly draws their attention (and those watching the movie). “Skip” then barks out an epic rant that would make Earl Weaver proud:
Skip: “You guys… You LOLLYGAG the ball around the infield. You LOLLYGAG your way down to first. You LOLLYGAG in and out of the dugout. You know what that makes you? Larry!”
Larry: “LOLLYGAGGERS!”
Skip: “LOLLYGAGGERS. What’s our record, Larry?”
Larry: “Eight and 16.”
Skip: “Eight and 16. How’d we ever win eight!?!”
So, in summary, a hilarious scene from a baseball movie taught me early on that lollygagging is not a good thing. I am now seeing that it is also a bad way to start off the early stages of your software development project. Think about it – as a team, once we clear that release hurdle, our instinct is to stop, take a deep breath, and relax. We just hit a major milestone, and more than likely the team worked some intense hours, days, weeks and sprints leading up to the actual release. (No matter how good your team is or how well you apply agile techniques, the days leading up to a release are ALWAYS more intense than those at the outset of a project.)
Picture the scene: our big release is deployed over an entire weekend, and everyone arrives to work on Monday. Whatever velocity, urgency and momentum generated and sustained through the prior release has seemingly dissipated into thin air. Because our next release is several weeks or months out, a feeling of tranquility sets in, as if the level of urgency no longer exists. We have now become…wait for it…OH NO! LOLLYGAGGERS!
This period of relaxation, or lollygagging, poses many threats to the next phase of the project.
That next release schedule – which was planned and completed last week and is now posted on the team room wall for everyone to see? Unfortunately, that new release schedule does not include any extra time for and does not tolerate relaxation, tranquility, or LOLLYGAGGING in the early sprints of the next release.
Due to the team carryover (with little or no change in personnel) the work to be done in Sprint #1 of the succeeding release is also likely projected based on established velocity from earlier sprints (i.e., the previous release). A slow, unproductive start to the first few sprints will undoubtedly result in a negative cascading effect on the entire release. For example: your release plan calls for 200 points with another production deployment after 10 sprints, because your team has proven time and time again this is an achievable goal (i.e., team velocity ~20 points). Your first two sprints start slowly and end up totaling 20 points, which already puts the team in trouble and in catch-up mode. Nobody likes being in catch-up mode. And catch-up mode tends to have a snowball effect.
Unless the release plan provisions for it, don’t allow carryover from the previous production deployment (or any associated issues or complications) to bleed into the early phases of the new release. Lollygagging will set in if team members continually remain in the mindset of the preceding release – in other words, looking back and not forward. Make sure the page is turned quickly on the weekend of the release (i.e., over to product support) and not turned slowly in the following few weeks.
As mentioned earlier, this behavior isn’t usually noticeable early on, but in those last few weeks before the subsequent deployment, when things become hectic and crazy again, everyone will wish they all hustled a bit more in the early weeks of the project.
Don’t get me wrong – celebrate the occasion! We’re not robots, and I’m a firm believer in recognizing and/or celebrating milestones at the end of a sprint or even better, after a successful production deployment. Those team milestones and achievements that we recognize working as teams are one of my favorite concepts of Scrum. But the party, or I should say, ‘mental break’, should not last for four weeks.
Here’s another way to think of it, and yes, we’ll use another baseball analogy. There is a baseball maxim which is often spoken at this time of the year. When a baseball team with high expectations opens the season with a poor start, you’ll often hear the following quote (or something similar):
“You can’t win the pennant in April, but you can certainly lose it.”
Keep that in mind when your next release starts – you can’t guarantee a successful project or production deployment in the first couple sprints of your new release, but if you come out of the gate slowly and LOLLYGAGGING, things can certainly come off the rails in a hurry. And everyone will be paying the price a few months later as the release date draws near.
The solution is simple, right? Make “Skip”, “Crash” and me proud, and just DON’T BE A LOLLYGAGGER!
Pete Rose, aka “Charlie Hustle”, was certainly not a lollygagger. He surely wouldn’t allow any of his teams to lollygag through the first few sprints of a release.
The Durham Bulls, on the other hand, captured the true essence of lollygagging. I can assure you that in this scene, only one or two people were actually concentrating on baseball.
Recently, I was part of a successful implementation of a project at a big financial institution. The project was the center of attention within the organization mainly because of its value addition to the line of business and their operations.
The project was essentially a migration project and the team partnered with the product vendor to implement it. At the very core of this project was a batch process that integrated with several other external systems. These multiple integration points with the external systems and the timely coordination with all the other implementation partners made this project even more challenging.
I joined the project as a Technical Consultant at a rather critical juncture where there were only a few batch cycles that we could run in the test regions before deploying it into production. Having worked on Agile/Scrum/XP projects in the past and with experience working on DevOps projects, I identified a few areas where we could improve to either enhance the existing development environment or to streamline the builds and releases. Like with most projects, as the release deadline approaches, the team’s focus almost always revolves around ‘implementing functionality’ while everything else gets pushed to the backburner. This project was no different in that sense.
When the time had finally come to deploy the application into production, it was quite challenging in itself because it was a four-day continuous effort with the team working multiple shifts to support the deployment. At the end of it, needless to say, the whole team breathed a huge sigh of relief when we deployed the application rather uneventfully, even a few hours earlier than what we had originally anticipated.
Once the application was deployed to production, ensuring the stability of the batch process became the team’s highest priority. It was during this time, I felt the resistance to any new change or enhancement. Even fixes to non-critical production issues were delayed because of the fear that they could potentially jeopardize the stability of the batch.
The team dreaded deployments.
I felt it was time for me to build my case to have the team reassess the development, build and deployment processes in a way that would improve the confidence level of any new change that is being introduced. During one of my meetings with my client manager, I discussed a few areas where we could improve in this regard. My client manager was quickly onboard with some of the ideas and he suggested I summarize my observations and recommendations. Here are a few at a high level:
It’s common for these suggestions to fall through the cracks while building application functionality. In my experience, I have noticed they don’t get as much attention because they are not considered ‘project work’. What project teams, especially the stakeholders, fail to realize is the value in implementing some of the above suggestions. Project teams should not consider this as additional work but rather treat it as part of the project and include the tasks in their estimations for a better, cleaner end product.
A long while ago, the Boston Consulting Group (BCG) pushed its limited and ill informed conception of Lean by focussing on waste elimination. It defined what most of us believe Lean to be to this day.
Six Sigma, with relatively good mathematical science – but not perfect according to Donald Wheeler – jumped on the bandwagon of certifications with its famous – and no less dogmatic & command and control – belt structure. Although Six Sigma always quotes chapters and verses from the statistical work of the likes of Donald Wheeler, we never heard the likes of Wheeler endorse ‘Sick Stigma’ (a term borrowed from Dave Snowden) ! (Having read all of Wheeler books, I never saw a reference to Six Sigma anywhere)
A recent study from QualPro, a consulting firm that advocates an alternative quality process, points out that 53 of 58 large companies that use Six Sigma have trailed the S&P 500 ever since they implemented it. As if on cue, once-mighty proponents of the program have begun to scale back their involvement, if not abandon it outright. Two of the most recent dropouts: 3M and Home Depot. In fact, Robert Nardelli, the former CEO of Home Depot, was forced out in part because his Six Sigma program was blamed for plummeting customer satisfaction and employee morale. At 3M, management is rolling back many Six Sigma initiatives: The program, it decided, was not compatible with the spirit of innovation that had once made 3M great. Invention is an inherently risky, wasteful and chaotic process—exactly the sort of stuff Six Sigma seeks to eliminate
Coming back to software development, those 7 wastes were the focus of the earlier book by Mary and Tom Poppendieck, where both merely transposed the 7 wastes as it were to software development. Later books proved to be better aligned with the essence of value creation, which is the foundation of Lean.
The essence of Lean, as depicted by David Anderson’s lean decision filter, is where we should stand : a) Value trumps flow, b) Flow trumps waste elimination, c) Waste elimination trumps economies of scale.
Waste elimination is a distant third focus. But neither BCG nor Six Sigma truly understood the spirit of Lean.
Lean Kanban University’s teachings focus on Value first where the flow of work is visually illustrated with the dominant knowledge activities driving product development. Waste is of course addressed in a system’s thinking approach inspired from the scientific work of Goldratt and Demings.
Daniel Doiron is an Accredited Kanban Trainer (AKT) who works closely with CC Pace to deliver Kanban training and coaching to our clients.
We have all heard the saying, “it’s all about who you know”. Job seekers today find that to be truer than ever, with U.S. News and World Report stating that two-thirds of the candidates employees refer get hired.
What gives these candidates the advantage? It’s a pretty simple fact that word-of-mouth marketing for job opportunities has been going on, well…forever. That is why many employers offer referral programs within their companies.
Employees bring in high quality candidates and help to simplify the entire recruiting process. The referring employee does their due diligence and pre-screens the candidate against the set requirements laid out for a specific position. That makes things move along faster for both the recruiter and hiring manager. Another piece in the process that is considered, is the fact that referrals have a longer retention rate within an organization, and it actually makes for a better work environment as these new employees come in seeing a familiar face to help ease their transition period. These referrals save the company time and money.
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 check out our latest opportunities as often as you’d like and refer away!
Is the RFP dead? As a tool for helping guide the selection of the best possible loan origination software, the traditional Request for Proposal seems to be increasingly viewed as an optional, and not particularly helpful, part of the selection process these days. And for good reason.
We at CC Pace have been questioning the value of a formal RFP for LOS selection, at least as typically applied, for some time now. Traditionally, the RFP is used to serve two primary functions: 1) to provide an apples-to-apples comparison of features and functionality among a group of worthy competing systems and vendors, and 2) to provide helpful documentation to the selection decision. But in today’s origination software market, the functionality included with competitive systems is more alike than ever before. LOSs have matured such that the differentiating factors are most often “how” they do things, not “what” they do. The RFP is simply not well suited to “how” distinctions, as “yes or no” questions are geared more for “what” and seldom shed light on the more nuanced distinctions of the candidate systems. In short, why bother asking detailed functionality questions when what is really needed is a better understanding of how each system handles those features that are “make-or-break” factors in your search?
The big problem for many lenders trying to navigate the software selection process is getting too caught up on debating the merits of a plethora of “bells and whistles,” while largely ignoring the bigger questions of whether the system meets their most important criteria and can they be successful in implementing it? In most situations there are only a relatively small number of things that really define what is absolutely critical, so why not limit the RFP to a short list of things you want the vendors to provide detailed answers on? Beyond that, well-orchestrated, in-depth system demonstrations typically do a better job of telling you whether a given system will meet your functional needs in a way that will fit well with your company’s organizational culture and processes.
Once having used detailed demonstrations to narrow the field to a small number of seemingly suitable candidate systems, the most important things a lender should want to focus on are 1) which of the systems can be successfully deployed in my shop and 2) will we be happy with the results afterwards? As simple as they may seem, these questions are exactly what you should strive to figure out in the process of selecting a system. And surprisingly they are often left out of the selection process entirely.
Too often lenders try to answer the first question (can we successfully deploy the system?) by looking at who the vendor has sold the system to recently. Many attempt to shorten the selection cycle simply by accepting that if Company ABC and XYZ bought the system, it must be good, without regard as to whether ABC or XYZ have successfully deployed it as yet, or if they’ve even begun that process. The truth is that not every LOS implementation goes all that smoothly, with something like a quarter of them failing outright. Rather than asking the vendor about their track record for successful implementation, it is far better to speak to as many customers of that vendor as possible and ask them directly. Probe into how their implementation efforts went, how happy were they with the vendor through that process, what kind of attention they received, and whether everything went as planned. Most of your lending brethren will be remarkably candid about this process when asked, even if the response doesn’t reflect all that well on them or the vendor. Use that candor to your advantage and learn from it.
Then ask how similar ABC and the others are to your company. When it comes to an LOS, one size does not fit all, so success with one company may not mean that much if they aren’t very similar to your company. Do they have the same operational model, offer the same products, and leverage the same channels? Ask them what level of effort was required of their own resources and how well prepared they were to meet those demands. Make sure you are ready to hold up your end of the implementation bargain, so listen carefully to what those that have succeeded tell you. Don’t over-reach by choosing a system that demands in-house analytical, configuration or development skills that you aren’t well-suited to provide, as those are critical factors when assessing suitability of organizational fit and common contributors to implementation struggles.
When it comes to being happy with the resulting system post-deployment, once again we strongly suggest doing your homework by talking to the vendors’ customers. Speak to as many current clients of the system as possible and ask probing questions about their satisfaction. Be honest with them about your expectations and goals and solicit their feedback on whether the system, in their opinion, can deliver. Here again the real trick is to not set yourself up to fail. Take the time to document your expectations up front, then carefully vet whether the system under consideration is truly aligned with those expectations.
The goals you are trying to achieve by replacing an existing LOS should be your north star guiding the process from start to finish. The desired outcomes should be things far more substantial than just successfully implementing a system. Clearly defining those desired outcomes at the outset is critical to guiding the implementation process, and to measuring your success at completion. Focusing the selection process on how to meet your critical needs while increasing the likelihood of successful deployment and roll-out is the right approach and one that relies very little on the traditional RFP.
So, should the RFP be laid to rest? My vote would be “no.” The RFP can provide important value, but skip the lengthy laundry list of functionality check boxes. Keep it short, ask open ended questions and focus on those critical things that are the real “make or break” factors in your search. But more importantly, the RFP should only be the start of your due diligence, used to help narrow the field before launching into asking the really big questions of whether you can succeed and by happy with your choice.
Still a bit overwhelmed with the selection process? Let’s talk.
Remember when you applied for a job, you would scan advertisements in the newspaper searching for a position that you were interested in? Then, you would submit a well-written cover letter and your resume to the address in the ad. If you were qualified, a recruiter or human resources associate would contact you as the next step to schedule an interview. If you were being considered for the position, the company would ask you for references. Once those references were checked out, and were to the satisfaction of the hiring company, they would then proceed by sending you an offer letter.
Jump ahead to 2017: you see a job posting online you would like to apply for, you submit a resume immediately through the website, or apply online. A recruiter or hiring manager will review your resume and then do a quick Google search to see if they can find your social media footprint. They want to see: How searchable are you? Who do you know? What level of engagement do you have on social media? Can they get a read on your personality, will you fit into the culture at this company? Do your initial credentials check out? Are there any red flags that come up in your search results?
Chances are all of this has happened before you even get a phone screening, so how do you strike the correct balance in managing your social media image? This article. Is your social media presence hurting your job search?, shares some great tips on how to navigate through your social media channels.
“Your Majesty,” [German General Helmuth von] Moltke said to [Kaiser Wilhelm II] now, “it cannot be done. The deployment of millions cannot be improvised. If Your Majesty insists on leading the whole army to the East it will not be an army ready for battle but a disorganized mob of armed men with no arrangements for supply. Those arrangements took a whole year of intricate labor to complete”—and Moltke closed upon that rigid phrase, the basis for every major German mistake, the phrase that launched the invasion of Belgium and the submarine war against the United States, the inevitable phrase when military plans dictate policy—“and once settled it cannot be altered.”
Excerpt From: Barbara W. Tuchman. “The Guns of August.”
In my spare time, I try to read as much as I can. One of my favorite topics is history, and particularly the history of the 20th century as it played out in Europe with so much misery, bloodshed, and finally mass genocide on an industrial scale. Barbara Tuchman’s book, The Guns of August, deals with the factors that led to the outbreak of WWI. Her thesis is that the war was not in any way inevitable. Rather, it was forced on the major powers by the rigidity of their carefully drawn up war plans and an inability to adjust to rapidly changing circumstances. One by one, like dominos falling, the Great Powers executed their rigid war plans and went to war with each other.
Although the consequences are far less severe, I occasionally see the same thing happen on projects, and not just software projects. A lot of time, perhaps appropriately, perhaps not, is spent in planning. The output of the planning process is, of course, several plans. Inevitably, after the project runs for a short while, the plans begin to diverge from reality. Like the Great Powers in the summer of 1914, project leadership sees the plans as destiny rather than guides. At all costs, the plans must be executed.
Why is this? I believe it stems from the fallacy of sunk cost: we’ve spent so much time on planning and coming up with the plans, it would be too expensive now to re-plan. Instead, let’s try to force the project “back on plan”. Because of the sunk cost of generating the plans, too much weight is placed upon them.
Hang on, though. I’ve played up the last part of the quote above – the part that emphasizes the rigidity of thinking that von Moltke and the German General Staff displayed. What about the first part of his statement? Isn’t it true that “the deployment of millions cannot be improvised”? Indeed it is. And that’s true in any non-trivial project as well. You can’t just start a large software project and hope to “improvise” along the way. So now what?
I believe there’s great value in the act of planning, but far less value in the plans themselves. Going through a process of planning and thinking about how the project is supposed to unfold tells me several things. What are the risks? What happens at each major point of the project if things don’t go as planned? What will be the consequences? How do we mitigate those consequences? This kind of contingency planning is essential.
Here’s how I usually do contingency planning for a software development project. Note that I conduct all these activities with as much of the project team present as is feasible to gather. At a minimum, I include all the major stakeholders.
First, I start with assumptions, or constraints external to the project. What’s our budget? When must the product be delivered? Are there non-functional constraints? For example, an enterprise architecture we must embed within, or data standards, or data privacy laws?
Next, I begin to challenge the assumptions. What if we find ourselves going over budget? Are we prepared to extend the delivery deadline to return to budget? I explore how the constraints play off against each other. Essentially, I’m prioritizing the constraints.
Then comes release planning. I try to avoid finely detailed requirements at this point. Rather, we look at epics. We try to answer the question, “What epics must be implemented by what time to generate the Minimum Value Product (MVP)?” Again, I challenge the plan with contingencies. What if X happens? What about Y? How will they affect the timeline? How will we react?
I don’t restrict this planning to timelines, budgets, etc. I do it at the technical level too. “We plan to implement security with this framework. What are the risks? Have we used the framework before? If not, what happens if we can’t get it to work? What’s our fallback?”
The key is to concentrate not just on coming up with a plan, but on knowing the lay of the land. Whatever the ideal plan that comes out of the planning session may be, I know that it will quickly run into trouble. So I don’t spend a lot of time coming up with an airtight plan. Instead, I build up a good idea of how the team will react when (not if) the plan runs aground. Even if something happens that I didn’t think of in the planning, I can begin to change my plan of attack while keeping the fixed constraints in mind. I have a framework for agility.
Never forget this: when the plan diverges from reality, it’s reality that will win, not the plan. Have no qualms about discarding at least parts of the plan and be ready to go to your contingent plans. Do not let “plans dictate policy”. And don’t stop planning – keep doing it throughout the project. No project ever becomes risk-free, and you always need contingencies.
No matter what kind of work we do, we look for feedback from our customers, our co-workers and our peers. Why do we do that? To improve and to get better at what we do. The same thing applies to Agile teams and programs, no matter what methodology the team is following: Scrum, Kanban, XP, SAFe, LeSS, or DAD.
A good retrospective is the key to helping teams improve what they are doing. It helps them identify and streamline processes which can create efficiencies and get them to that next level of maturity. Hard to believe, but this is the event which is most commonly ignored or taken lightly. Teams often feel they are too busy and do not have time to retrospect. This makes the team get into a ‘Plan and Do – Plan and Do’, vicious cycle. They never stop to reflect and adjust and then they complain Agile doesn’t work.
An Agile Methodology isn’t magic and it doesn’t solve all problems by itself. It makes the problems transparent, clear and appear sooner in a project’s lifecycle. But to identify the problems and to find out what can be done differently to improve the processes, the teams need to retrospect.
So why don’t the teams do retrospectives? Here are some of the reasons they give:
Don’t have time just to talk, it’s a waste of time
Retrospectives are boring
No one takes any actions from the retrospectives so why bother
Same monotonous technique
Unplanned meeting
High performing team already, nothing more to improve on
No participation
So how do you make retrospectives interesting, add value to the team and make them a place where the team members can express their opinions without any repercussions?
First of all, the retrospectives should follow the “Vegas Rule” – what happens in Retrospectives stays amongst the team members. All of the information is shared in this container of trust and all team members and facilitators should respect the container. Information or data in the retrospectives is collected with the sole purpose of making the team better and improving processes. The information should not be used as performance management feedback.
Secondly, and most importantly, it is not intended to be a finger pointing session or to point out the skill or knowledge gaps in any individual team member. Retrospectives should always be respectful and be conducted professionally by a skilled facilitator (usually a Scrum Master).
Thirdly, the retrospectives should be done by selecting interesting activities that engage all team members. The activities should be relevant to what is happening in the team. They should let the entire team collect data, learn the insights and decide on what actions they can take together to improve.
Fourthly, the retrospectives should be made exciting! The teams which asks the same dreaded questions – what did we do well, what did we not do so well or any suggestions for improvements at the end of every sprint really gets boring and monotonous, not only for the team but for anyone facilitating the retrospective as well.
Create an environment of trust, honesty and make room for some creative retrospective ideas. It should be planned in advance so the team feels like it is a treat being part of a retrospective after the hard work in the sprint. It should allow the team to think about innovative ways in which they can adjust and make themselves and the processes better. The book by Ester Derby on making retrospectives great is an excellent resource and so is the website Tastycupcakes.org for activity ideas.
Next, what about the findings and action items from the retrospectives? Many tools like Version One have a section wherein the output of retrospectives can be created, stored and referenced in next retrospective. The best thing is to prioritize the resulting action items, assign them owners and place the list both in the online tool for distributed team members and on the physical board as an Information Radiator. Do a check-in on the retrospective action items and see if they are completed. Items can be added to the team’s backlog and be accepted by the team’s PO.
Just collecting feedback and forgetting about the retrospectives is what makes most people discouraged from holding retrospectives. When people feel that no action is taken and nothing changes, they wonder why they should keep on wasting time with this retrospective exercise.
Participation from all team members is key. Especially if you have some very quiet team members and others who have a lot of ideas and take over the meeting. Good facilitation skills come-in handy to address this concern. If the facilitator knows that some team members are reticent to jump in and be part of the conversation, they can ask direct questions to engage those team members so that everyone is heard and valued.
Lastly, no team is so high performing that they cannot retrospect or find anything else to improve. They might have found other mechanisms of inspecting what they are doing and how to adjust, such that they do not wait until the end of the sprint for this formal retrospective session. But they are still doing a retrospective, even if it’s all the time.
“Once I started looking around behind the port frames, I figured I could just….”
And so began a summer of endless sailboat projects and no sailing. One project lead to the start of another without resolving the first. What does this possibly have to do with software development and Agile techniques?
My old man and I own and are restoring an older sailboat. He is also in the IT profession, and is steeped in classic waterfall development methodology. After another frustrating day of talking past each other, he asked how I felt things could be handled differently in our boat projects.
“Stop starting and start finishing!”
It is the key mindset for Agile. Take a small task that provides value, focus on it, and get it done. It eliminates distraction and gives the user something usable quickly.
Applying this mindset outside of software may not be intuitive, but can pay dividends quickly. On the boat, we cleared space on the bulkhead, grabbed a stack of post-its and planned through the next project, rewiring the boat. The discussion started with the goal of the project. “We’re just to tear everything out and rewire everything.” Talk about ignoring non-breaking changes! I suggested that we focus on always having a working product – a sail-able boat – and break the project into smaller tasks that can be worked from start to finish in short, manageable pieces of time.
Approaching the project from that angle, we quickly developed a list of sub tasks, prioritized them, and put them up on our make-shift Kanban board. This was planning was so intuitive and rewarding on its own that we did the same for other projects we want to tackle before April.
So stop starting, start finishing, and start providing value quicker for your stakeholders.
As we move further into the 21st century and our technologies continue to advance, it is changing the landscape for all aspects of business, including job searching. The key question every candidate needs to be asking is, “what’s new with job hunting in 2017?” This article from AOL discusses the 2017 Trends for Job Seekers to watch.
Today, in the United States alone, 85% of companies have a Facebook page, and 94% of recruiters use social media to find high-quality candidates. These numbers alone are incredibly high, but think about it, who do you actually know that doesn’t use some form of social media (grandparents excluded)? At CC Pace we maintain a strong social media presence for all aspects of our company, and continue to seek the best candidates for our job opportunities frequently using Linked In and Facebook, as well as other forms of communications.
Traditional methods of sending a resume and cover letter are being passed by with video screenings and online communications. Remember that advice you have heard repeatedly: be careful what you post on the internet because once you put it out there, it’s out there forever? That has never been more true. There is nothing worse than finding a qualified candidate and having to pass them over for a position based on what is found when a hiring manager Googles their name. The same goes for the hiring company, savvy job hunters are researching you just as thoroughly.
CC Pace joined Cornerstones in December for their annual winter coat event. CC Pace’s corporate contribution in conjunction with employee donations provided 20 coats for this important drive. Cornerstones offers the donated coats to those in need from November through March.
Cornerstones is a nonprofit organization that promotes self-sufficiency by providing support and advocacy for those in need of food, shelter, affordable housing, quality childcare, and other human services.
CC Pace takes pride in supporting our community by offering corporate contributions and participating in various events throughout the year.
Do you ever think about why there are some things in your life that that you do year in and year out, while others fall by the wayside? For me, I’ve played in a Thanksgiving neighborhood football game every year since we moved into our house in 1994 and I’ve gone on a golfing trip to Las Vegas with some high school and college buddies since my wife arranged the first one for my 40th birthday (she might have re-thought the idea had she known it would become an annual event). While you likely don’t know early on what will have staying power, certain events become meaningful in the tradition they become, the camaraderie they build, and the enjoyment they create both during the event and throughout the year telling stories about it.
While these examples cited above have limited to no societal significance, one tradition of mine that does is my attendance at the annual gala for So Others Might Eat (SOME) which just recently occurred. I’ve been on SOME’s Corporate Advisory Board for the past 18 years and I’ve attended every one of their annual galas during that time except for one (I hope one unavoidable personal conflict in 18 years is excusable).
A little about SOME: SOME was founded by Father Horace McKenna in 1970 as a soup kitchen to feed DC’s homeless. Under the extraordinary vision and leadership of Father John Adams, SOME expanded its purpose and has taken a more holistic approach to address this critical issue. On top of serving nearly 400,000 meals per year, SOME now offers a comprehensive set of programs to meet the needs of the homeless and to directly address some of the root causes that keep one homeless. These include: medical and dental clinics; a drug rehabilitation facility; behavioral health services; temporary, transitional, and permanent affordable housing; and a center for employment training. As best expressed in its Mission Statement, SOME is “restoring hope and dignity one person at a time”.
Notwithstanding the enormous number of volunteers who donate their time to the organization, these programs require money to operate. As its major fundraising event, SOME holds its annual Gala to celebrate its work, to present the SOME McKenna Humanitarian award (this year’s honorees were Raul Fernandez, CEO, Object Video and Vice Chairman, Monumental Sports and Linda Jo Smith, Chair, SOME Board of Directors), and to support their programs. Many of this year’s proceeds are earmarked towards development of a brand-new facility on Benning Road in DC that will include housing, job training, a medical clinic, offices and retail. This building will greatly expand on SOME’s ability to serve the needy.
As soon as the gala date is announced, I block it off on my calendar. So why do I attend every year?
It is a tradition that I look forward to and an event that I enjoy attending. I love the camaraderie among SOME’s Corporate Advisory Board who, like me, religiously attend and support the event. And I get immense enjoyment and personal satisfaction, in this case from hearing about the impacts that we are making in helping to address this significant societal problem that would only get worse if not for organizations like SOME.
Somewhat the same reasons as my annual football game and golf trip, but with a whole lot more purpose.
Father John Adams, President of SOME
When I am out providing Agile classes, the topic of what Scrum Masters do all day comes up pretty frequently. Attendees ask questions like; “How many teams can a ScrumMaster be part of?”, and “Do Scrum Masters just run meetings?”. As a veteran of Scrum, I am still surprised at how little organizations understand about the ScrumMaster role. But let’s face it, attending a 2 or 3 day Certified ScrumMaster course provides only an introduction to the Agile Framework, Scrum Events and Roles. Experience and a desire to truly understand what it means to be Agile and how Scrum embraces these principles takes time. It’s an ongoing learning that extends beyond just getting certified.
So let’s start with the basics. The single word most often used to describe the ScrumMaster role is “Facilitator”. Here is the Merriam-Webster’s definition
Definition of Facilitator:
one that facilitates; especially: one that helps to bring about an outcome (as learning, productivity, or communication) by providing indirect or unobtrusive assistance, guidance, or supervision <the workshop’s facilitator kept discussion flowing smoothly>
How does a ScrumMaster facilitate while being “indirect or unobtrusive”? First, you need to understand where your team and organization fit on a scale from just starting their journey to practicing best practices as a highly performing team. I say this because new teams do need a little more “hand holding”, than teams that have been together for a while, and are experienced following Scrum. The ideal goal is to get the teams to work via self-organizing, while motivating them by ensuring they have the right tools and support. ScrumMasters promote the team’s work, not their own work.
The Scrum Guide (see http://www.scrumguides.org/scrum-guide.html) lists three groupings of work for the Scrum Master: 1. Service to the Product Owner 2. Service to the Development Team 3. Service to the Organization. This requires that the ScrumMaster have several skills they can call on at any time depending on where the need is. Nowhere in the Scrum Guide does it say the ScrumMaster is the boss, the secretary, or the project manager of the team.
So, let’s go back to what it means to be a facilitator by looking at a scrum event. ScrumMasters do typically organize getting all the scrum events set up. Ideally scrum events are on a cadence to occur at the same time, and in the same place whenever possible. ScrumMasters facilitate events by ensuring the space is appropriate for the job at hand, all needed supplies are available, and that the appropriate attendees have been invited. The following is an example of how Sprint Planning is facilitated by the ScrumMaster:
Sprint Planning The goal of Sprint Planning is to identify what can be delivered and how the work will be achieved.
The Scrum Master ensures all stories being presented in Sprint Planning meet the Definition of Ready by working with the Product Owner in advance of the meeting.
The ScrumMaster provides the container for the meeting, and turns it over to the Product Owner to work with the team providing the sprint goal and a conversation to promote a thorough understanding of the stories proposed for the upcoming sprint.
The team moves on to designing how they will do the work and tasking the stories, while the ScrumMaster listens and watches to ensure there is a shared understanding and that the team members have an equal voice. The ScrumMaster can facilitate by ensuring the team stays focused and doesn’t get stuck by asking questions, inviting others with specific technical expertise to join the conversation, and managing the time box of the event.
The final step is when the ScrumMaster calls for the team to commit to delivering the work.
There are many great web articles that list things a Scrum Master does. Here are a couple of good ones:
Aside from facilitators, ScrumMasters are also the team’s protector, an overall evangelist and enforcer of the Scrum method, and a coach.
Surprised? What does the ScrumMaster do in your organization? Are there improvements that can be made? I welcome your feedback, questions and comments.
Outside of my work at the MSRB for CC Pace, I enjoy working with community organizations in Fairfax County. After eight years of running the Jefferson Manor Civic Association, I was named Chairman of the Lee District Assoc. of Civic Orgs (LDACO). This is an organization focused on improving communications between residents in the Lee District section of Fairfax, and the elected officials and staff of the county. I have been involved with the board of directors for several years, and was bursting at the seams with ideas on how to build on the foundation I had inherited.
The nearly unlimited options quickly brought about a familiar end result – paralysis. Ideas ranged from simple house-keeping to epic public festivals. It was, to be honest, complete chaos.
Thankfully, at the time I was working on my understanding of Agile techniques and how they applied to my work situation. A key source for this was ‘The Nature of Software Development” by Ron Jeffries. As the pages flew by, the point of always prioritizing value became clear. How could this perspective be focused on running an advocacy group for civic associations? The clouds parted and the way forward became clear.
Prioritize by what would provide immediate value to the organization and its members. Again referring to Jeffries, I used the “Five Card Method” to determine what our first ‘epics’ to tackle would be. The idea is pick three to five big ticket items that will provide immediate value, and focus on breaking those down into manageable pieces.
How do we determine what our members find valuable? Ask them. A review of LDACO’s contact list showed that it was incomplete and in some cases, outdated. We had no social media outreach, either. Improved, direct communication became epic #1.
Talking with leaders in other communities, as well as long standing members of LDACO, I learned that folks needed a longer lead time to plan on attending our meetings. Epic #2 was to provide a calendar of events with at least 90 days out.
Lastly, LDACO learned that our members wanted a district and county-wide focus for meetings and speakers. While having a very narrow topic may provide value for a single community, it did not translate to the diverse group as a whole. Epic #3 was to aim for big, broad topics with speakers who were involved in the decisions that impacted the largest number of communities.
These became the main focus of LDACO’s work for the past year. These were broken down into smaller, achievable pieces, then worked on and completed. In the past year, we have grown our communication list, begun to grow on social media, and increased our attendance and membership through meetings with important stakeholders. All because we kept the focus on what provided value for our customers.
CC Pace was ready when we hosted our Thursday Night Football Tailgate Party, which included both current employees and CC Pace alumni! The evening was filled with a festive BBQ menu, drinks, fun and fabulous door prizes! We were happy to have a number of CC Pace Alumni join us as we gathered and watched the Virginia Tech vs Pittsburgh game on the big screen. Luckily, for all the Hokies we had in attendance, Virginia Tech was able to bring home the win in a tight game with a final score of 39-36.
To make the evening even more entertaining, we held a cornhole tournament with single elimination rounds. Champions George Perkins, CC Pace Staffing Director and Tracy Gordon, wife of President, Mike Gordon were the last team standing after a score in the game of 0-14. They pulled off a huge comeback to claim the title and win the grand prize – Congratulations George and Tracy!
All in all it was a win-win evening for everyone!
In Scrum, the User Story represents the main item in the Product Backlog. However, it is not the only item in the backlog. So let’s take a look at other items in the Product Backlog.
According to the Scrum Guide, “The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.”
For the purpose of simplicity, we group the backlog into four types of items:
User Stories
Technical Stories
Spikes
Defects
Let’s take a look at each type of item.
User Story
Written in the format: As a Type of User, I Want to do something, So that why do I want it. User stories are not complete without Acceptance Criteria and a discussion with the team to gain the full requirements of the story. User stories cover features, functions, enhancements, and epics. Typical guidance is that a user story can be completed in 2 days or less, while some experts say the work of the team on a story may last up to a week. Whether you call large User Stories epics, themes, or features may depend on what tool you are using, or how you were trained. User Stories originate from XP where any large story needing to be broken down was called an Epic. As these large stories were broken down, we could actually tear up the Epic as it was being replace with multiple smaller stories. Product Owners may not have the skills to break stories down as small as they need to be for a Sprint. This is where the team comes in during grooming/refinement to help break down stories and discover gaps. Our tools (Version One, Rally, Jira, etc) allow us to maintain a parent child relationship using the labels like Epic, Theme, or Feature.
For tips on writing user stories check out this link.
User Stories can be written by anyone. They are often written during user story workshops where the team and stakeholders are together brainstorming user actions and system needs. The goal of the Product Owner is to thoroughly understand stakeholders needs in order to create and explain the User Stories in the backlog. For me, the PO or their surrogate are the main writers of user stories for end user applications. PO’s are the ones that will typically be engaging stakeholders. So while they may get some help in writing the stories, they are still the ones accountable for ensuring complete understanding, and to accept the story as the work is completed.
Technical Stories
Technical Stories represent any technical work the team must undertake during a sprint. While it is possible to use the typical user story format by identifying ‘the who’ as something that isn’t really a person, like “System X”. However, I ask teams I’m working with: is there any value in writing Technical stories in this format? For me, where there is no benefit, there is no reason to write technical stories in the user story format. A simple statement will work, e.g. “upgrade test tool”. While the format of a user story isn’t needed, it is still important to include acceptance criteria. Team members typically write these stories, and let the PO know where in the backlog they should sit in order to be completed in a timely manner, often as a predecessor to doing other user stories.
For more on writing Technical Stories look here check out what Mike Cohn says about using the FDD format here.
Spikes
Spikes are done for knowledge acquisition. Spikes should be time-boxed, and have specific acceptance criteria. A team member may ask for a spike in order to do some research, proof-of-concept, or prototyping to gain knowledge prior to working on a set of user stories. There is no reason to write spike in user story format. The maximum duration for a Spike is the length of a sprint. Another attribute of Spikes, is that they should be the exception and not the rule.
Defects
As users work with the system, and testers test the system, bugs or other defects may be found. For me, these are not the same as rejecting a current user story because it fails testing. User Stories that fail testing are rejected and reworked within the sprint if time allows. If time doesn’t allow, the PO can decide if the story will be in the next sprint or not, and the team will not get points for the story until it passes test.
As other defects or bugs are found in the system new user stories are written to identify the desired functionality. The PO will stack rank these PBI’s along with all other stories.
Recently, several employees gathered together to help out the local Ronald McDonald House. The Ronald McDonald house is a place where families of patients who are in the hospital can go to spend the night, have a meal, and rest while they are visiting their family members in the hospital. The house, located in Falls Church, supports all of the local hospitals and can house up to 8 families at a time. See more information here.
CC Pace employees prepared a delicious meal for the families and staff including: vegetable beef soup, garden salad, cornbread, cookies and brownies. In addition, our employees collected a variety of supplies, arts and crafts, and puzzles to go into activity bags for the patients in the hospitals, as well as the family members taking care of them.
Thank you to Beverly, the house night manager, for her help and giving us a tour of this wonderful house.
In Daniel H. Pink’s book, Drive: The Surprising Truth About What Motivates Us, he discusses the motivations of knowledge workers. He makes the case that knowledge workers are driven by intrinsic factors and not the extrinsic factors of punishment and money. As he states, “Carrots & Sticks are so last Century. Drive says for 21st century work, we need to upgrade to autonomy, mastery, and purpose.” A great video covering his work is viewable at https://youtu.be/u6XAPnuFjJc. For most research on extrinsic and intrinsic motivation start with the work of Edward Deci from the 1970s.
Here is an explanation of the three types of motivation:
Autonomy
This is the granting of control over their own work to those doing the work. Guidance is fine, but too much and it becomes the micro-management which can be detrimental to motivation. Valuable feedback, performance metrics, and boundaries can be all that is needed.
Mastery
This is an innate desire to get better at doing some task. If it is too easy, workers may get bored. If it is too hard and little progress is made, workers often get frustrated and give up. So tasks must be challenging, yet doable. And fostering an environment of continuous learning will add to motivation.
Purpose
This is tying the work to a cause larger than themselves. Workers, who believe in that cause, feel that there is importance to the outcome of the work beyond just their own accomplishment.
DevOps?
According to Wikipedia:
DevOps is a software development method that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other information-technology (IT) professionals.
That certainly sounds like knowledge work to me. But are the three motivations the same for software developers and operations staff? And what might they be in a DevOps team. Let’s take a look in the chart below:
The management challenge then is to create a supportive culture where DevOps can flourish and the knowledge workers will be highly motivated by having aligned motivations of Autonomy, Mastery, and Purpose.
If I told my 6-year-old daughter, Gracie, to get out a piece of paper and a pencil, she would likely get out a pencil and a piece of paper. But if I made the same request of my officemate, Ron, he would likely look at me funny and ask me why. Of course, if I made the same request of my 14-year-old daughter, she would completely ignore me but that’s another story.
So why the difference in reactions from Ron and Gracie? It really boils down to how we learn. As children, we learn by being fed information. During our early academic career, we take what teachers tell us as gospel. However, as we get older, we begin to question authority, as if it’s a sort of rite of passage to adulthood. I can hear those of you with teenagers, passionately shaking your heads. What I am trying to say is that adult learners need to be involved in the learning process. As adults, we need to understand why we are in this learning experience and how it’s going to make our lives better.
Um, CC Pace is an Agile coaching and training company, why are you talking about learning stuff?
Well, I am glad that you’re paying attention. Aside from the fact that CC Pace recently hired me to focus entirely on creating effective learning programs and I gotta do something to show them that I actually know stuff, how we learn stuff is part of how we create lean, mean, efficient machines…er, organizations. Just because you consider yourself an Agile environment doesn’t mean that you actually are! Waving the magic wand does not make a company Agile, although it’s kinda fun to suggest it to the senior leadership team to see if they bite. Agile needs to be embraced at the top AND at the bottom. Getting buy-in from the folks in the trenches means that the training needs to be created with them, very clearly, in mind.
Think of the last time you had to go to training because management said so, or because of a requirement for some regulation. What did you learn? Did you pick up lots of good stuff? Would you wish it on your worst enemy? Learning experiences that fulfill a check box are often set up for failure because we forget to explain how this information will ultimately help the learner. If we just chalk it up to a requirement or some mandate, then we have missed an opportunity to help reinforce the content.
It’s critical that a successful learning program understand that key difference; that adult learners need to be engaged with the process, rather than as just a passive participant.
So how do we get the learners engaged? Well, hopefully, you can see where I am going with this. If we start by successfully demonstrating how this information will connect back to the participant, then we stand a much better chance of helping the learner retain the information. Otherwise, participants are left pondering all of the other ways that they could be wasting time while still on the clock. But if the participant sees why the training will impact them, then they will submit to the learning process.
And as Johnnie Cochran once so famously said, “If the training reason is legit, then you must submit!” Ok, so Johnny never said that, but I bet he would have if he read this post. Ok, that might be a bit of a stretch, too. But it’s a nice way to remind ourselves of the importance of setting up a training for success. Keep this in mind when you are planning Agile training for a team within your organization. Thanks for sticking with me this long, how about we pick this up next time with some more ideas on building engagement in your learning program?
Picture this: you’ve recently been hired as the CIO of a start-up company. You’ve been tasked with producing the core software that will serve as the lynchpin for allowing the company’s business concept to soar and create disruption in the market. (Think Amazon, Facebook, or Uber.) Lots of excitement combined with a huge amount of pressure to deliver. You’ve got many decisions to make, not the least of which is whether or not to build an in-house team to develop the core system or to outsource it to a software development consultancy. So, how do you decide and to whom do you turn to if you do opt to outsource?
CC Pace is one of the software development consultancies that a company might turn to as we focus in the start-up market. Developing greenfield systems for an innovative new company is an environment that our development team members greatly enjoy.
A question that has been posed to me fairly frequently is: why would a start-up company outsource their software development? While I had my own impressions, I decided to pose the question to some CIOs of the start-up companies we’ve worked with, along with some CEOs who ultimately signed-off on this critical decision.
The answers I received contained a common theme – neither approach is necessarily better, and the proper decision depends on your specific circumstances. With some of these circumstances being inter-related , here are the 4 primary factors that I heard the decision should depend on:
Time-to-Market – It takes time to assemble a quality team, often up to 6 months or more. Even then, it will take some additional time for this group to jell and perform at its peak. As such, the shorter the time-to-market that the business needs to have the initial system delivered, the more likely you would lean toward an outsourced approach. Conversely, if there is less time sensitivity, it makes sense to put in an in-house team. This team will be able to not only deliver the initial system, but they will also be able to handle future support and development needs without requiring a hand-off.
Workload Peak – For some new businesses, the bulk of the system requirements will be contained in the initial release(s) while others will have a steady, if not growing, stream of desired functionality. If the former, hiring up to handle the initial peak workload and then having to down-size is not desirable and can be avoided with the outsourced model. On the other hand, a steady stream of development requirements for the foreseeable future would cause you to lean towards building an in-house team from the start.
Availability of Resources – While there is a scarcity of good IT resources seemingly everywhere, certain markets are definitely tighter than others. In addition, some CIOs have a greater network of talent that they know and could more easily tap than others. The scarcer your resource availability, the more likely you would lean in calling upon outsourced providers. Conversely, if you have ready access to quality talent, take advantage of that asset.
CIO Preference – Finally, some CIOs just have a particular preference of one approach over the other. This may simply be a result of how they’ve worked predominately in the past and what’s been successful for them. So, going down a path that’s been successful is a logical course to take. Interestingly, one CEO commented that his decision in choosing a CIO would be that person’s ability to make these types of decisions based upon the business needs and not personal preference.
I would love to hear from anyone who has been (or will be) involved in this type of decision either from the start-up side or the consulting provider side, as to whether this jives with your experience and thinking. The one variable that wasn’t mentioned by anyone as a factor was cost. That surprised me a lot and I’d also welcome any of your thoughts as to why this wasn’t mentioned as a factor.
Well, actually, let’s go watch a baseball game! After our recent staff meeting, many CC Pacers climbed aboard a bus and we headed downtown to Nationals Park to watch the Washington Nationals play the Colorado Rockies. Upon arrival, we were rewarded with our very own Max Scherzer Bobblehead.
Although it was a hot and humid day, there was an abundance of refreshing beverages available. We also enjoyed lots of the traditional ball park food including; hot dogs, pretzels in the shape of a W, peanuts and cracker jacks! But let’s not forget dessert, the delicious Breyers’ ice cream that helped us cool down a bit.
Despite the hot day, it was a great event and we enjoyed spending time together, having fun and rooting for the Nationals. Our efforts paid off and the Nationals beat the Rockies 8 – 5, including a home run from one of our favorite players, Jayson Werth. What a great way to end the evening!
“There I was on assignment for a month in the Sahara Desert of Northern Africa during a time of the year that was supposed to be fairly mild. Unfortunately, there was a heat wave during most of that month, which drove temperatures into the mid 120’s. With little to no shade, relentless flying and crawling insects, and sparse meals that caused me to lose 20 pounds, I continued to work toward getting that ‘perfect shot’, at the perfect time. This assignment proved to be the most physically demanding I ever endured. Nonetheless, I’d choose that job every day over an unstimulating project.”
So goes the story of a high school friend and renowned photographer, Don Holtz, whose impressive work includes the likes of Tom Hanks, Morgan Freeman, Steven Spielberg, Time Magazine and chronicling the Foo Fighters. Yet despite his amazing success, Don humbly shared with me (when asked) that there is no perfect time for taking the perfect shot. Instead, he explained, it is by the continued effort of working ‘toward’ perfection that he is able to achieve the highest level of success.
Similar to Don’s challenges in Africa, mortgage bankers continue to maneuver stringent regulations, weak GDP growth, and persistently low interest rates that limit their ability to help grow the local or national economy. As a result, most lenders are content to maintain a conservative approach to lending while instructing their IT departments to tweak or revamp old and disparate technologies in order to keep management, maintenance and overall IT project costs down rather than pursue innovation and rethink how business could be done better. Basically, most are waiting for the ‘perfect time’ to rebuild, reengineer and transform their business.
Conversely though, there are nearly 80 million millennials (18 to 34 years old) in the US who are actively shifting from renting to home buying as their family’s needs grow. In a recent study by the National Association of Realtors (NAR), millennials were the largest share of home buyers in 2015, at 31%. All evidence points to this trend actually increasing throughout 2016.
Just consider that the millennial generation, who has maximized the use of Snapchat, Facebook, Facetime and texting to such an extent they do not know of any other way to live, communicate or do business, is now the greatest force driving home buying. This should put pressure directly on the backs of mortgage bankers to re-think and rebuild century-old banking and lending practices in order to successfully support this new generation of borrowers. Millennials are first and foremost a tech-savvy generation of borrowers who are fiercely brand loyal (think Apple) and seeking to do business with firms that speak their language of fast, easy and friendly, supported by best-in-class technology platforms.
Over the last thirty-six years, CC Pace has helped implement scores of mortgage banking technology platforms supporting strategic initiatives and business transformation projects, but never have we seen a greater need than exists today for business transformation in mortgage banking. Business transformation is desperately needed that will successfully help to attract and support the new generation of home buyers. Such projects require lenders to challenge their organization’s own institutionalized thinking in order to evaluate all aspects of the firm’s strategy, its lending process, its technology and equally importantly, how they provide the service levels this generation requires. Business transformation is needed not just to entice the millennial generation, but to earn their loyalty for return business as well.
Certainly embarking on new large-scale business transformation projects is stressful and risky (which is why firms hire CC Pace). But the alternative of risking alienation of the millennial borrower generation by failing to meet their needs and expectations will prove to be devastating to lenders who choose to continue a conservative approach to facing the future of mortgage lending.
When I asked Don what he thinks it means when people indicate they are waiting for the perfect time to take the perfect shot, he said, ”The idea of perfection is more dependent on a state of mind than on external conditions that we can’t always control.” He went on to highlight how he takes responsibility for how he will respond to changing conditions, spending his energy planning, as best he can, to arrive at a shoot prepared to adapt his game plan for both the existing and changing conditions to ensure the best possible outcome. As Don put it, “There is no perfect time, but that doesn’t mean you don’t continue to work ‘toward’ perfection.” This is as true for mortgage bankers as it is for world-class photographers. If you aren’t working toward transforming to meet the demands of the market, you will never achieve greater success. So as lenders continue to expect mild temperatures, they may soon find themselves in the middle of a heat wave. There is no perfect time; there is no perfect shot. Success can only be achieved by actively working toward the goal of perfection.
Don Holtz is the owner of Don Holtz photography services. If you are interested in Don’s services he can be reached athere.
Do you remember the questions on standardized tests where they asked you to pick the thing that wasn’t like the others? Well, this isn’t a fair example as there are really two distinct groups of things in that list, but the names of TDD philosophies have become as meaningless to me as the names of quarks. At first I thought I’d use this post to try to sort it all out, but then I decided that I’m not the Académie française of TDD school names and I really don’t care that much. If the names interest you, I can suggest you read TDD – From the Inside Out or the Outside In. I’m not convinced that the author has all the grouping right (in particular, I started learning TDD from Kent Beck, Ron Jeffries and Bob Martin in Chicago, which is about as classic as you can get, and it was always what she calls outside in but without using mocks), but it’s a reasonable introduction.
Still, it felt like it was time to think about TDD again, so instead I went back to Ron Jeffries Thoughts on Mocks and a comment he made on the subject in his Google Groups Forum. In the posting, Ron speculated that architecture could push us a particular style of TDD. That feels right to me. He also suggested that writing systems that are largely “assemblies of OPC (Other People’s Code)” “are surely more complex” than the monolithic architectures that he’s used to from Smalltalk applications and that complexity might make observing the behavior of objects more valuable. That idea puzzles me more.
My own TDD style, which is probably somewhere between the Detroit school, which leans towards writing tests that don’t rely on mocks, and London schools, which leans towards using mocks to isolate each unit of the application, definitely evolved as a way to deal with the complexity I faced in trying to write all my code using TDD. When I first started out, I was working on what I believe would count as a monolithic application in that my team wrote all the code from the UI back to right before the database drivers. We started mocking out the database not particularly to improve the performance of the tests, but because the screens were customizable per user, the data for which was in a database, and the actual data that would be displayed was stored across multiple tables. It was really quite painful to try to get all the data set up correctly and we had to keep a lot more stuff in mind when we were trying to focus on getting the configurable part of the UI written. This was back in 1999 or 2000, and I don’t remember if someone saw an article on mocking, but we did eventually light on the idea of putting in a mock object that was much easier to set up than the actual database. In a sense, I think this is what Ron is talking about in the “Across an interface” section of his post, but it was all within our code. Could we have written that code more simply to avoid the complexity to start with? It was a long time ago and I can’t say whether or not I’d take the same approach now to solving that same problem, but I still do find a lot of advantages in using mocks.
I’ve been wanting to try using a NoSQL database and this seemed like a good opportunity to both try that technology and, after I read Ron’s post, try writing it entirely outside-in, which I always do anyway, and without using mocks, which is unusual for me. I started out writing my front-end using TDD and got to the point that I wanted to connect a persistence mechanism. In a sense, I suppose the simplest thing that could possibly work here would have been to keep my data in a flat file or something like that, but part of my purpose was to experiment with a NoSQL database. (I think this corresponds to the reasonably common situation of “the enterprise has Oracle/MS SQL Server/whatever, so you have to use it.) I therefore started with one of the NoSQL implementations for .NET. Everything seemed fine for my first few unit tests. Then one of my earlier tests failed after my latest test started passing. Okay, this happens. I backed out my the code I’d just written to make sure the failing test started passing, but the same test failed again. I backed out the last test I’d written, too. Now the failing test passed but a different one failed. After some reading and experimentation, I found that the NoSQL implementation I’d picked (honestly without doing a lot of research into it) worked asynchronously and it seemed that I’d just been lucky with timing before they started randomly failing. Okay, this is the point that I’d normally turn to a mocking framework and isolate the problematic stuff to a single class that I could either put the effort into unit testing or else live with it being tested through automated customer tests.
Because I felt more strongly about experimenting with writing tests without using mocks than with using a particular NoSQL implementation, I switched to a different implementation. That also proved to be a painful experience, largely because I hadn’t followed the advice I give to most people using mocks, which is to isolate the code for setting up the mock into an individual class that hides the details of how the data is set up. Had I been following that precept now that I was accessing a real persistence mechanism rather than a mock, I wouldn’t have needed to change my tests to the same degree. The interesting thing here was that I had to radically change both the test and the production code to change the backing store. As I worked through this, I found myself thinking that if only I’d used a mock for the data access part, I could have concentrated on getting the front-end code to do what I wanted without worrying about the persistence mechanism at all. This bothered me enough that I finally did end up decoupling the persistence mechanism entirely from the tests for the front-end code and focus on one thing at a time instead of having to deal with the whole thing at once. I also ended up giving up on the NoSQL implementation for a more familiar relational database.
Image from http://martinfowler.com/bliki/BeckDesignRules.html
So, where does all this leave my thoughts on mocks? Ron worried in his forum posting that using mocks creates more classes than testing directly and thus make the system more complex. I certainly ended up with more classes than I could have, but that’s the lowest priority in Ken Beck’s criteria for simple design. Passing the tests is the highest priority, and that’s the one that became much easier when I switched back to using mocks. In this case, the mocks isolated me from the timing vagaries of the NoSQL implementations. In other cases, I’ve also found that they help isolate me from other random elements like other developers running tests that happen to modify the same database tables that are modifying. I also felt like my tests became much more intention-revealing when I switched to mocks because they talked in terms of the high-level concepts that the front-end code dealt with instead of the low-level representation of the data of the persistence code needed to know about. This made me realize that the hard part was caused by the mismatch between the way the persistence mechanism (either a relational database or the document-oriented NoSQL database that I tried) and the way I thought of the data in my code. I have a feeling that if I’d just serialized my object graph to a file or used an object-oriented database instead of a document-oriented database, that complexity would go away. That’s for a future experiment, though. And, even if it’s true, I don’t know how much I can do about it when I’m required to use an existing persistence mechanism.
Ron also worried that the integration between the different components is not tested when using mocks. As Ron puts it in his forum message: “[T]here seems to be a leap of faith made: it’s not obvious to me that if we know that A sends the right messages to Mock B, and B sends the right messages to Mock A, A and B therefore work. There’s an indirection in that logic that makes me nervous. I want to see A and B getting along.” I don’t think I’ve ever actually had a problem with A and B not getting along when I’m using mocks, but I do recall having a lot of problems with it when I had to map between submitted HTML parameters and an object model. (This was back when one did have to write such code oneself.) It was just very to mistype names on either side and not realize it until actual user testing. This is actually the problem that led us to start doing automated customer testing. Although the automated customer tests don’t always have as much detail as the unit tests, I feel like they alleviate any concerns I might have that the wrong things are wired together or that the wiring doesn’t work.
It’s also worth mentioning that I really don’t like the style of using mocks that really just check if a method was called rather than it was used correctly. Too often, I see test code like:
I would never do something like this for a method that actually returns a value. I’d much rather set up the mock so that I can recognize that the calling class both sent the right parameters and correctly used the return value, not just that it called some method. The only time I’ll resort to asserting a method was called (with all the correct parameters), is when that method exists only to generate a side-effect. Even with those types of methods, I’ve been looking for more ways to test them as state changes rather than checking behavior. For example, I used to treat logging operations as side-effects: I’d set up a mock logger and assert that the appropriate methods were called with the right parameters. Lately, though, with Log4Net, I’ve been finding that I prefer to set up the logger with a memory appender and then inspect its buffer to make sure that the message I wanted got logged at the level I wanted.
In his Forum posting, Ron is surely right in saying about the mocking versus non-mocking approaches to writing tests: “Neither is right or wrong, in my opinion, any more than I’m right to prefer BMW over Mercedes and Chet is wrong to prefer Mercedes over BMW. The thing is to have an approach to building software that works, in an effective and consistent way that the team evolves on its own.” My own style has certainly changed over the years and I hope it will continue to adapt to the circumstances in which I find myself working. Right now I find myself working with a lot of legacy code that would be extremely hard to get under test if I couldn’t break it up and substitute mocks for collaborators that are nearly impossible to get set up correctly. Hopefully I’ll also be able to use mocks less, as I find more projects that allow me to avoid the impedance between the code’s concept of the model and that of external systems.
Yoga Pants? Sweats? Shorts? Pajamas? Working from home full-time is more than just having the option of turning on your laptop in comfortable lounge wear. It is learning how to be and remain an effective and productive contributor to your company.
Technology advances have made working remotely easier for workers. In the United States, the percentage of work-at-home employees, among the non-self-employed population, has grown by 103% since 2005 according to GlobalWorkplaceAnalytics.com. Approximately 10% of CC Pace’s workforce is distributed across the country and work remotely. In addition, a high percentage of other staff members have the option to telecommute at least one day a week.
How does a home-based employee stay both productive and connected? This article presenting 3 Tips for Productive Remote Work from the Huffington Post gives some sound advice for those workers to follow. It discusses working through shared/cloud based documents with your team; regular calls, emails and open tasks boards; and when the opportunity arises, getting in that all important face-to-face time. CC Pace Senior Consultant, Greg Self, home-based in Dallas, Texas, says to stay relevant and in touch, “Our Financial Services Consulting practice has a weekly meeting to get caught up on current and upcoming client work. Along with those calls, we communicate through regular emails during the week to management on status updates and engagement happenings.”
Another area that plays a key role in successfully working remotely is the infrastructure and support provided by the employer. CC Pace Agile Consultant, Jannette Brace, based in the Seattle, Washington area says, “CC Pace is very good at providing the necessary tools for working remotely. They also budget for trips for remote employees to visit the home office multiple times throughout the year, including the Annual Party which is always a great event!”
Forecasts currently show that by the year 2020 more than 30% of the workforce will be working remotely on a full-time basis – wonder where your desk will be?
Fairfax Corner offers more than just outdoor shopping, dining, and entertainment it is also the place CC Pace has called home for the past 13 years. As one of Fairfax Corner’s first tenants, we moved into our suite located on the fourth floor in the office building at the top of the plaza in October 2003, and had the opportunity to put our name on the side the building. CC Pace found being based in Fairfax Corner would offer employees close proximity to I-66, Fairfax County Parkway and Route 50, a variety of restaurants, free parking, shopping, personal services and a picturesque setting to greet them on a daily basis.
Over our time in this location, we have all come to enjoy the many offerings that Fairfax Corner provides from the splash fountain and free summer activities that include Concerts at the Corner, Little Tots, Yoga on the Plaza to the year-round variety of holiday activities and festivals. We are also conveniently located near the Fairfax County Government Center, Wegman’s and Fair Oaks Mall. Want to catch an event or game at George Mason University after work? No problem as it’s only about 10 minutes away.
Fairfax Corner is growing and is currently expanding its’ presence with the addition of a 950 space parking garage and a new 5 story office building. The garage is opening this summer and the office building is scheduled to open next year.
As you can see, our employees have much to enjoy and many endless options that are always evolving around here at Fairfax Corner. It’s a great place to work!
We are currently seeking a Business Development/Account Representative in our IT Staffing Division to identify new business opportunities, as well as grow and maintain existing accounts. The role focuses on selling staff augmentation services – contract, temp-to-perm, and permanent IT placement positions. Within the role there will also be the opportunity cross-sell other CC Pace services, such as Agile Training, Custom Application Development and Financial Consulting services. Applicants must be highly motivated, outgoing, and relationship-focused.
Job Responsibilities
Establishing relationship with hiring managers, understanding their business objectives and needs, and working with the recruiting team to identify qualified candidates for opportunities
Generating business opportunities through cold calls, referrals, and business meetings
Gathering and qualifying job opportunities with hiring managers. Effectively communicating position qualifications with the CC Pace recruiting team
Developing account plans and strategies
Building long-term mutually beneficial relationships with clients
Managing on-going contact with clients and consultants to ensure both are equally satisfied
Job Requirements
At least 3 years of experience in IT Staff Augmentation as an Account Rep or Recruiter
Demonstrate strong drive for results and success; convey a sense of urgency to achieve outcomes and exceed expectations; persistent, despite obstacles, setbacks, and competing influences
Ability to build a network and mine for client contacts and accounts
Demonstrate self-motivation with the ability to establish goals and achieve results
Proven success achieving sales objectives and quotas
Strong interpersonal, verbal, and written communication skills
Ability to maintain a positive attitude in a fast-paced, ever-changing industry
Uber. Eight years ago, the company did not exist and the word was simply a rarely used adjective of German origin meaning “ultra”, like an uber intellectual. Today, Uber has become one of the most successful startups in history and the word has become a commonplace verb in English parlance. Transcending to “verb” status puts Uber in the highly exclusive class of innovative business disrupters like Google and FedEx whose business names and processes have become synonymous with an action that didn’t previously exist but is now done on a regular basis. Who today wouldn’t understand what actions you had taken if you said, “I quickly googled the address for the nearest drop-off spot and uber-ed over there so I could fed-ex my package out on time”?
Uber owns no cars, has no drivers, and has minimal fixed assets. Instead, they created an incredibly user-friendly software that improves aspects of the taxi ride industry we didn’t know needed improvement. Not surprisingly, the full legal name is Uber Technologies, Inc. While the only technologies typically found in traditional taxi cabs are the decades old meter clicking away the increments of the cost of your ride, the Uber software provides new value to both the driver and the customer with useful information such as the location of both the driver and the customer, time estimate for pick-up, exact pricing, car options, driving directions, and much more.
By creating this simple way to get a ride, Uber has reached another pinnacle accomplishment whereby the creativity of its business model has become a noun: uber-fication. According to Dr. Paul Marsden in his Reading Room article, The Uberfication of Everything, “…the real genius of Uber lies in a deep understanding of convenience – what it is and why it matters. That’s what Uberfication is all about; pivoting your business to deliver on a core under-exploited consumer need – convenience”.
One thing that every startup has is a dream and a vision. But, let’s be honest, that simply isn’t enough to successfully build a booming new business like Uber. You need the right partners, you need money, and you need passion for the project at hand. We believe that we can help in all these areas, which lead us to formalize an offering exclusively for startups.
When I formed CC Pace nearly 36 years ago, I was driven by a vision of a new model for a consulting company – one where integrity and the client’s best interest were ingrained in the firm’s culture and successful delivery could almost be guaranteed by the quality, drive and teamliness of the employees who worked there. While my dream may not have been as wide-reaching as Uber, when I think back to that time, I just remember energy, excitement and that ‘anything is possible’ feeling. Over the years, we’ve been very fortunate to work with clients in all phases, from startups to Fortune 500 organizations—all of which we value a great deal. I get excited to work with clients of all sizes, but there is something about working with startups that brings about an energy that you can’t replicate in other environments. Being a part of someone else’s vision coming to life brings me right back to where I stood over 35 years ago and is an environment in which I’ve seen our project teams thrive in.
Our experience working with startups combined with our project teams’ passion has lead us to formalize an offering to help startups get off the ground with the right technology. To enable us to work on more of these type of efforts, we are officially launching a new risk/reward program for startups. Here, we are able to combine our technical prowess with our business acumen that result in a software component that fully and effectively supports the start-up’s vision. The premise of our offering is to build the technological platform for your business with less cash required. In exchange for this discount, we agree upon a fair share of some downstream benefits of your startup reflective of the risk we take.
If you like the idea of maintaining control of your vision while paying less up-front to get the results you need, then I would love to hear from you. Interesting companies with challenging technology needs has been a driver for us for over 35 years. For this reason, we are confident that we have the ability to help better enable your dream. After all, it’s only a matter of time before the next “Uber” shocks the world.
For more information on the risk/reward program, check out our offering here.
Have you heard that not all Agile Transformations are successful? Have you wondered what makes some transformations more successful than others? Are you wondering if your organization can be successful?
Here is a little analogy to think about. I recently lost 40 pounds on an eating transformation plan, or more simply a diet. I don’t like to call it a diet, because if I ever go back to my old way of eating I’ll likely gain my weight back. Also if I don’t follow the basic guidelines of the diet, I may not lose weight at all. So what does this have to do with being successful at Agile?
When organizations pick and choose what principles to follow in Agile, it’s like low carb dieters choosing to still eat potatoes, or white bread on their diet. While they may see some improvements, overall they are not setting themselves up for success on this plan. The diet gets blamed rather than how the dieter chose to implement the diet.
When preparing for a transformation, the first step is to get the foundational pieces right. Learn about the plan. Prepare your house by cleaning out your cupboards and fridge, and shop for the good stuff to replace the bad stuff. Learn what the rules of your plan are, and set a date to begin. Note, a new eating plan works better if everyone in the house is on the same plan! Then measure the results, and make corrections as needed.
In an Agile transformation, the steps are much the same. Identify what method you want to follow within the Agile framework. Get everyone onboard by helping them learn about the methodology. Prepare your “house” by looking at the organizational structure and identifying what will work within the transformation and what won’t. Make a decision to replace the practices that don’t fit in the transformation with practices that will support a successful transformation. Inspect and Adapt to keep improving and making course corrections along the way.
So what if your organization doesn’t want to follow the plan to the letter? It’s OKAY… BUT the organization needs to know the impact of alterations in the plan. If I can’t give up my potatoes what does that mean? Will I see the same success rate? How can I compensate for keeping my potatoes?
Some Agile principles are more easily adapted than others. I can counteract teams not being co-located for “face-to-face” interactions, by providing great tools for them. I can bring those team members together for planning sessions, or other occasions to help build the team rapport, and offset the lack of co-location. Other principles aren’t so easily adapted. A poor company culture where trust and empowerment are lacking, may prove to be too much to overcome, leaving the organization with unmotivated and un-empowered teams.
If your transformation has hit a plateau, or doesn’t seem to be working. It may be time to take a look at how you are following the new plan, and where your potato-eating cheats are causing you bloat, and derailing your success. It may not be the method, but rather how you are following it.
As Wall Street analysts predict smartphone sales will continue to level off due to varying levels of market saturation, does that actually mean smartphone utilization is set to follow? Is the smartphone honeymoon over? Is the saying ‘there is an app for that’ dead? Perhaps the sales of new smartphones are in fact tapering off, but I am a firm believer that ‘utilization’ is just getting started.
Since the turn of the Century, each new generation of trains, planes and automobiles continues to be enhanced in order to increase consumer satisfaction and society’s overall productivity. With each new generation they become faster, easier, and cheaper to run and maintain, and lighter, smaller and in many cases even more luxurious. Why should the smartphone be any different? It has revolutionized how we store, manage and transport information. In the short term, the smartphone has allowed people to immediately ditch the bulky briefcase loaded down with a calendar, address book, calculator, plane tickets, a newspaper and manila folders to that of just a handheld device which simply fits into a shirt pocket.
The invention of the smartphone is on par to that of the automobile. Society’s overall successful adoption of the smartphone has been in an effort to help increase one’s ‘quality of life’. With that said, it’s quickly becoming high noon in the world of business where the lack of an effective smartphone strategy for both customers and employees will likely seal the fate of said business. Most at risk may in fact be the financial services industry, given the volume of legacy systems built and now required to support some of the most comprehensive of services and investment products. The up and coming millennial generation has made it blatantly clear they will adopt those who have successfully adapted. Moving forward it’s incumbent on a business that their success, let alone their survival will be dependent on their smartphone e-strategy. So in reading the following article, it confirmed my belief that the smartphone generation is just getting started. Read more about it in Strategy+Business, “Radical Intimacy and the Smartphone”.
CC Pace remains committed to helping guide organizations in the development, deployment and adoption of their e-strategies.
Looking for a new job or Staffing Assignment? Here are some tips from American Staffing to help you land that position. They give you helpful hints in how to construct/format your resume, putting together a cover letter as well as some interview tips. These helpful hints can be used for finding or interviewing for a permanent full time opportunity or a subcontracting/consulting assignment.
In my personal experience working on various software development projects, the concept of team energy often appears to be either undervalued or benignly ignored by management teams. The reasons are many. First of all, the term may be confused with “team velocity” which is a relative measurement of a team’s average output or productivity. If the velocity appears to be at either predictable or positive levels, the management team may choose to believe that team energy is also at satisfactory levels. Organizations may attempt to boost employee morale by putting together team-building exercises and outing events. This macro approach may result in generating a perceived positive effect on team energy, thus obscuring the need for focus on individual teams. So, what is team energy and why should managers consider devoting some attention to it?
When thinking in terms of team energy, one can look at it as building credit with each individual team. One can also look at it from an analogy of having a rainy day fund. From a management’s standpoint it is important to keep team energy in the positive territory. This helps ensure that the team will likely empower themselves to exceed expectations, as well as step up during times of crisis or high pressure situations. I have worked in high energy teams, in which members voluntarily pushed themselves past regular working hours to produce deliverables. These cases did not involve any direct increase in compensation or promotion. People naturally wanted to succeed because they possessed enough energy to do so. I have also witnessed the opposite, where a team’s energy was low, deliverables were in a perpetual state of tardiness and the backlog was steadily accruing bugs. Developers and testers did not feel empowered to succeed and entered a cycle of doing the absolute bare minimum to “get the management off their back”.
Science behind building teams
Agile methodologies, whether Scrum or Kanban, prescribe various techniques that are focused on continuous improvement that may positively affect team energy. Regardless of whether an organization has truly embraced Agile, it is difficult to find managers that would oppose efforts in improving a team’s processes of delivering faster and at a higher value. After all, who is against a boost in productivity? There is a hidden psychological component to continuous improvement that has a causal effect on team energy. This component is more associated with the experience of individual team members.
Studies of team dynamics such as ones conducted by MIT’s Human Dynamics Laboratory, and documented in Harvard Business Review suggest that there is a science to building high performing and high energy teams. One of the keys is to focus on the human brain and social dynamics of a group. Your teams may be composed of introverts as well as extroverts and a wide range of personalities, but there is a common factor that seems to persist. The studies show that humans feel good when they achieve their goals and overcome obstacles. A human brain actually rewards its owner with extra levels of dopamine when a goal is achieved. When the team feels good more often than not, the team energy goes up. When the opposite occurs, team energy goes down. Therefore, focusing on small achievable goals not only helps the organization to shift focus of deliverables, but it also fosters this psychological benefit of achievement for each individual team member.
Measurements
An organization may choose to periodically measure team energy. One way to achieve such measurement is through anonymous surveys. Usually this is done at a more enterprise level to gauge the overall organization energy. There is certainly value in doing that, but the effort is not focused and may not necessarily apply to teams. Small teams may not produce very accurate results. There may be disincentives to be frank when answering a survey because team members may feel singled out and fear reprisals from management. In addition, more introverted team members may choose not to “rock the boat”. A more effective and team-focused approach is to have an Agile coach periodically take team energy measurements. An opportune time may be during team retrospectives, when a team is usually more receptive to be candid. Most importantly, these measurements do not need to be secretly stored in a manager’s vault but should be shared with the team. Adding transparency to the team building and management process will not only increase team energy, but also foster leadership skills among the more proactive and extraverted team members.
I’m just returning to work after Spring Break in Cancun. I’ve met some lovely people while enjoying the sunshine. As I chatted with those beside me at the beach and alongside the pool, two common questions are asked: What is your name? and What do you do for a living? The answer to the first question is easy, but the answer to the second question is much longer. Why? Because I can’t just stop with “I’m a trainer”. I enjoy talking about Agile and Scrum, and explaining the basic framework. I enjoy sharing with others how they can apply what I teach to just about anything. I enjoy sharing Agile stories because Agile works, and I like talking about how companies can adopt an Agile mindset.
When I start talking to someone about Agile, I begin by explaining first how past processes have fallen short. The trials and tribulations of a 1 or 2 year project plan, managing risk, reaching or missing milestones, and change requests to re-baseline the plan for any number of reasons come to mind. All with a real concern of delivering something that misses the mark in “delighting the customer”. Waterfall projects often have cost overruns, extended delivery dates, and a plethora of change requests that aren’t discovered until near the end of the project during User Acceptance Testing (UAT). For these reasons, Waterfall just doesn’t feel like the best choice to deliver software anymore.
I then move on to talk about why I, and so many others, choose Agile processes to build software today. So here is a little of what I talk about:
Continuous engagement with the customer and other stakeholders is key
Seeing progress through continuous delivery enables better feedback
Reduced risk and waste, which can save money and heartache
Adapting to change quickly, which allows for the customer to respond to market changes
Better quality deliveries by testing early and often
It isn’t magic, and it isn’t necessarily an easy transition to make. To become a truly Agile organization takes a true shift in how we and everyone else in our organization thinks about how work is performed both internally, and externally with our customers.
Yes, I am a bit of an evangelist. Sometimes I want to shout from rooftops “people get it together, follow Agile principles”, “walk the talk”, “quit being stuck in the past”. Our world is evolving every day. To keep pace with our competitors, we need to evolve too. Agile is an umbrella term for a number of methodologies including Kanban and Scrum. Today we find that Agile isn’t just for software anymore. The principles and methods can be followed just about anywhere to greatly improve our ability to deliver just about anything. That’s why I’m not just a trainer, but a believer.
Well, it wasn’t actually a food fight with people throwing food at each other in a cafeteria, but rather a Food Fight to Battle Hunger! Last Friday, May 13th, CC Pacers joined hundreds of other volunteers to help package meals to be sent to starving children around the world. We participated in a mobile food-packing event sponsored by Feed My Starving Children that provides meals to children in over 40 countries. The event was held at the Dulles Expo Center located in Chantilly, VA, over the weekend of May 13th through May 15th. The goal of the event was to pack 5.1 million meals that would feed over 19,000 starving children worldwide for a year.
We started our session with lots of cheerleading from the event coordinators, donning very attractive hair nets, and energizing music to create lots of fun and excitement as we went to our packing stations. We all had a good time doing our jobs while dancing and singing to “Up Town Funk”, “YMCA”, “Twist and Shout” and lots of other great tunes.
By the end of our session, the CC Pace team had packed 1316 meals and all of the volunteers for that session, packed over 146,000 meals that will feed 402 children for a year!
Thanks to all the volunteers for helping out at this very worthwhile event. Already looking forward to the Food Fight next year!
Building a new software product is a risky venture – some might even say adventure. The product ideas may not succeed in the marketplace. The technologies chosen may get in the way of success. There’s often a lot of money at stake, and corporate and personal reputations may be on the line.
I occasionally see a particular kind of team dysfunction on software development teams: the unwillingness to share risk among all the different parts of the team.
The business or product team may sit down at the beginning of a project, and with minimal input from any technical team members, draw up an exhaustive set of requirements. Binders are filled with requirements. At some point, the technical team receives all the binders, along with a mandate: Come up with an estimate. Eventually, when the estimate looks good, the business team says something along the lines of: OK, you have the requirements, build the system and don’t bother us until it’s done.
(OK, I’m exaggerating a bit for effect – no team is that dysfunctional. Right? I hope not.)
What’s wrong with this scenario? The business team expects the technical team to accept a disproportionate share of the product risk. The requirements supposedly define a successful product as envisioned by the business team. The business team assumes their job is done, and leaves implementation to the technical team. That’s unrealistic: the technical team may run into problems. Requirements may conflict. Some requirements may be much harder to achieve than originally estimated. The technical team can’t accept all the risk that the requirements will make it into code.
But the dysfunction often runs the other way too. The technical team wants “sign off” on requirements. Requirements must be fully defined, and shouldn’t change very much or “product delivery is at risk”. This is the opposite problem: now the technical team wants the business team to accept all the risk that the requirements are perfect and won’t change. That’s also unrealistic. Market dynamics may change. Budgets may change. Product development may need to start before all requirements are fully developed. The business team can’t accept all the risk that their upfront vision is perfect.
One of the reasons Agile methodologies have been successful is that they distribute risk through the team, and provide a structured framework for doing so. A smoothly functioning product development team shares risk: the business team accepts that technical circumstances may need adjustment of some requirements, and the technical team accepts that requirements may need to change and adapt to the business environment. Don’t fall into the trap of dividing the team into factions and thinking that your faction is carrying all the weight. That thinking leads to confrontation and dysfunction.
As leaders in Agile software development, we at CC Pace often encourage our clients to accept this risk sharing approach on product teams. But what about us as a company? If you founded a startup and you’ve raised some money through venture capital – very often putting your control of your company on the line for the money – what risk do we take if you hire us to build your product? Isn’t it glib of us to talk about risk sharing when it’s your company, your money, and your reputation at stake and not ours?
We’ve been giving a lot of thought to this. In the very near future, we’ll launch an exciting new offering that takes these risk sharing ideas and applies them to our client relationships as a software development consultancy. We will have more to say soon, so keep tuning in.
No matter what kind of work we do, we look for feedback from our customers, our co-workers and our peers. Why do we do that? To improve and to get better at what we do. The same thing applies to Agile teams and programs, no matter what methodology the team is following: Scrum, Kanban, XP, SAFe, LeSS or DAD.
A good retrospective is the key to helping teams improve what they are doing. It helps them identify and streamline processes which can create efficiencies and get them to that next level of maturity. Hard to believe, but this is the event which is most commonly ignored or is taken lightly. Teams often feel they are too busy and do not have time to retrospect. This makes the team get into a Plan and Do – Plan and Do vicious cycle. They never stop to reflect and adjust and then they complain Agile doesn’t work.
An Agile Methodology isn’t magic and it doesn’t solve all problems by itself. It makes the problems transparent and clear and appear sooner in a project’s lifecycle. But to identify the problems and to find out what can be done differently to improve the processes, the teams need to retrospect.
So why don’t the teams do retrospectives? Here are some of the reasons they give:
Don’t have time just to talk, it’s a waste of time
Retrospectives are boring
No one takes any actions from the retrospectives so why bother
Same monotonous technique
Unplanned meeting
High performing team already, nothing more to improve on
No participation
So how do you make retrospectives interesting, add value to the team and make them a place where the team members can express their opinions without any repercussions?
First of all, the retrospectives should follow the Vegas Rule – What happens in Retrospectives stays amongst the team members. All of the information is shared in this container of trust and all team members and facilitators should respect the container. Information or data in the retrospectives is collected with the sole purpose of making the team better and improving processes. The information should not be used as performance management feedback.
Secondly and most importantly, it is not intended to be a finger pointing session or to point out the skill or knowledge gaps in any individual team member. Retrospectives should always be respectful and be conducted professionally by a skilled facilitator (usually a Scrum Master).
Thirdly, the retrospectives should be done by selecting interesting activities that engage all team members. The activities should be relevant to what is happening in the team. Retrospectives should enable the entire team collect data, learn the insights and decide on what actions they can take together to improve.
Fourthly, the retrospectives should be made exciting. The team which asks the same dreaded questions – what did we do well, what did we not do so well and are there any suggestions for improvements at the end of every sprint usually don’t get to the crux of the matter. The retrospectives get boring and monotonous.
Create an environment of trust and honesty and make room for some creative insights. Retrospectives should be planned in advance so the team feels like it is a pleasure being part of the retrospective after all the hard work in the sprint. It should allow the team to think about innovative ways in which they can adjust and make themselves and the processes better. A book by Ester Derby on ways to use creative exercises in retrospectives is an excellent resource and so is the website Tastycupcakes.org.
Next, what about the findings and action items from the retrospectives? Many tools like Version One have a section wherein the retrospectives can be created, stored and referenced in the next retrospective. The best thing is to prioritize the items, assign them owners and place the list both in the online tool for distributed team members and on the Physical board as an Information Radiator. Do a check-in on the retrospective action items and see if they are completed. Retrospective items can be added to the team’s backlog and be accepted by the team’s PO.
Just collecting feedback and forgetting about the retrospectives is what makes most people discouraged from holding retrospectives. When people feel that no action is taken and nothing changes, they wonder why they should keep on wasting time with this retrospective exercise.
Participation from all team members is key. Especially if you have some very quiet team members and others who have a lot of ideas and take over the meeting. Good facilitation skills come in handy to address this concern. If the facilitator knows that some team members will not jump in and be part of the conversation, they can ask direct questions to engage those team members so that everyone is heard and valued.
Lastly, no team is so high performing that they cannot retrospect or find anything else to improve. They might have found other mechanisms of inspecting what they are doing and how to adjust, that they do not wait until the end of the sprint for this formal retrospective session. These teams have learned that improvement is always something to look forward to.
barbeque! This event was not only attended by our current employees, but by several CC Pace alumni as well. We enjoy staying in touch with our alumni and in many cases, have had the opportunity to work with them again. It’s always a good time to catch up with old friends, share some laughs and see what everyone is up to now.
Herndon, VA: Lean Agile DC. Jason Velentino (Director, Digital Reliability Engineering at Capital One) kicked off the conference with a great presentation on DevOps and his journey through incorporating cloud and a DevOps culture at such a large organization. It is rewarding for CC Pace to have been a part of the Agile adoption at Capital One, providing Agile Coaching and Training over the past five years and to see the evolution of Agile, which Capital One has made part of their everyday culture.
