Values in an Agile/Lean/Innovative company

This is part of my Lean Disruption Series where I’m looking at Lean, Agile, Innovation, and Lean Startup.

None of these methodologies can be adopted for free. They require a great deal of firm introspection. Understanding how processes interaction with people and values is vital to adopting any of these approaches let alone a combination of these approaches.

Metrics are one of the best examples of how there can be conflicts between stated values, values in making decisions, how resources are handled and how processes are structured. The famous saying “You manage what you measure” is right in a lot of ways. Many companies claim that they value customer satisfaction, however many of these companies do not actually do anything with the satisfaction surveys they do get. Comcast is the most obvious example of this. Comcast doesn’t really value customer satisfaction because they measure their customer support on how much they can upsell to the customer anytime they are on the phone. This changes the processes their customer support must use, rather than designing processes to enable single call resolution, their processes are designed to enable selling more products. Their employees, the resources, are rated based on this and if they don’t meet those goals they are unlikely to do well. Considering the Verge’s Comcast Confessions series most of the resources at Comcast do not feel valued. This all points to the true values for Comcast being retention at all costs and more revenue per user measured in Churn and ARPU (Average Revenue per User) respectfully.

Agile Manifesto from ITIL’s blog

For a company to adopt an Agile approach to developing software, the paradigm of what the organization values must radically change to align to the Agile Manifesto. In most software development the concepts on the right are what are valued through a Project Management Office. The concepts on the left are typically considered only at the beginning or the end of the project or not at all. Working product is the goal of a project, while customer collaboration inclusive only in the beginning getting requirements.

Switching from the right to the left creates massive cultural upheaval at an organization, where power is shifted down and out. It is shifted down to the team level, where managers in the past made all the important decisions Product Owners, Scrum Masters, and developers make the decision now with the customers. Power is shifted out through increased collaboration with the customer. Customer centricity forces the company to understand what the customer really wants and more quickly respond to changes in their understanding of their needs. This does mean that the “requirements” change, however, in many cases due to the uncertainty in a technology, interface, or some other aspect it was impossible to properly articulate the actual need until there was an example in front of the customer.

With these value changes there must be process changes to that properly reflect the change in the way the values require work to be completed. In the case where Single Call resolution is the most important metric reflecting the value of true customer satisfaction, processes must be built to enable that – such as training, information repositories, and authority to truly address customer needs at a single point of contact. In software development rapid iteration with continual feedback is a process that must be built to enable that.

This changes are not free and require true commitment from leaders across the organization. Without their commitment any adoption of these frameworks is doomed to failure.

HR, Recruiting, and Candidates

I read a well intentioned post on LinkedIn today that really got me thinking about the recruiting process. This being near and dear to my heart since I’m going through the process of finding a new job. While at my last job I was fortunate enough to be both a hiring manager for 2 employees and involved in the hiring process for 5 positions that would not be reporting to me. Discussing with my manager the different requirements for positions he and I aligned on one thing, we wanted the best person regardless of how they looked on paper. In many cases this directly conflicted with the requirements of HR since the salary bands the employees we were hiring for required degrees or certifications.

For example one of the Business Analysts we decided to hire didn’t have a college degree, but because of the salary band required to get high quality candidates we had to have a college degree as a requirement, even though we didn’t believe it was truly a requirement. This BA turned out a better hire than one of the other BAs that had a college degree and a great deal of BA experience. Another perfect is example is the face that one of my hires was “required” to have a nursing certification to earn the pay band we knew was required to find a highly qualified candidate. I had to fight HR and argued it wasn’t truly required for the position. I eventually won and the person I hired worked out amazingly well and in fact is more highly regarded than his counter part that has that certification. Finally, one of our POs for the product had neither certification nor college degree. He has done extremely well without those certifications – granted he earned a certification and a great deal of trial by fire experience, but he started out strong because of his business experience.

These are just examples from my personal experience. This is ignoring the number of great people that have become famous despite their credentials that would have had them relegated to the dust bin in less than 6 seconds by the recruiter above. If this is the best system our current Recruiting and HR experts have developed, it’s a deeply flawed system that needs some serious rework. Finding the right candidate is difficult. It requires team work between HR, Recruiting, and the Hiring Manager. These conversations and dissociation of salary and degree requirements from applications will likely reverse the trend of college degrees required for every position. I think our thought leaders in Recruiting and HR need to do better, the article above indicates there’s a great deal of waste and non-value added activity in the vetting process because a good fit that is excluded after 6 seconds is a defect and any candidate that looks good on paper but is clearly a bad fit is also a defect to the process.

The hiring process is extremely expensive as is the onboarding and training of a new hire. Any clear poor fit from the start indicates there defects and waste in the hiring process that need to be addressed. Bragging about a 6 second “review process” isn’t the right thing to be doing, figuring out how to fix the process to ensure that the right people are hired the first time at the right time should be the goal of recruiting.

Business, processes, and things to drive improvement

About a week ago I was at PegaWorld. I’ll tell you what, for a rather dry business application – business Process Management, those guys know how to party. That being said, it is a really powerful platform to help automate existing processes or to interact with other systems to put a wrapper around the inputs and outputs of that system. That’s pretty powerful. Pega is one of those pieces of software that has the potential to “disrupt” the way traditional software is built. Essentially it eliminates the need to actually develop software the old fashion way, and allows users to create process flows that then generate the underlying Java. Now that doesn’t mean all coding will go away, especially at the interface API level, but it’s still a huge step forward to leveling that playing field.

I think this raise an interesting point, software is going to eat the world according to a lot of VC type folks. However, what happens when a piece of software enables more people to do what software was enabling people to do? I think it’d drive down the cost of enabling automated solutions. Not only are there super high level “languages” like Pega, there’s also a great deal of higher level programming languages out there, such as Ruby on Rails, JavaScript, Python, and others that help to develop the application as you’re building it. Swift from Apple is another such language. It shortens the learning cycle. I’m partially through building an App in Rails and I’d never used it before, it’d be a lot harder to do the same in Java alone.

All of this really drives a concern – we could just automate bad processes. Things that doing faster don’t actually help any customer or ourselves actually accomplish any sort of goal. This is a problem if you don’t actually understand what you’re trying to do. This is something that I think a lot of startups miss – who cares that I can really efficiently do something, when some thing isn’t really worth doing? It’s a waste of time, energy and activity to do that. Software eating the world or other types of automation are only useful to anyone if they actually work to improve the underlying structure they are being built upon. PegaWorld had some interesting talks of people that looked into this, but it was basically tangential when it needs to be at the core of everything that’s happening.

Apparently in the show, Silicon Valley, every startup ends up saying that this product is going to make the world better. Simply saying that doesn’t make it so – I’m sure that Ubisoft and EA believe that their games are going to make the world a better place. You could argue that by excluding something from the next Assassins Creed game really did make the world better by driving a conversation about the choices that developers and companies make when bringing a product to market – and how poorly those decisions can go for the company that makes them. It’s important to understand the root cause of a problem as well as any risks changes pose to the business when you don’t deliver on something you are selling.