Tuesday, May 28, 2013

People vs. Process ... vs. Principles

“Be firm on principle but flexible on method.” -- Zig Ziglar

Until recently, I have observed the difficulties and issues manifested in the work environment and debated, both with myself and with peers, whether the root cause was the people being unskilled or unmotivated or the lack of a quality process. It was not until recently that I have come to realize that it is the founding principles on which we operate that makes the biggest difference in how successful we are.

When debating people versus process, the argument for people is that good people seem capable of producing amazing results regardless of process. However, I’ve seen great people time and again be suppressed by poor process, being forced into inefficiency for the sake of policy. In grass-roots meetings and informal conversations, both within my company and in conversations with others across the industry, I hear complaints of red tape, write-only documents, and wasteful tools and bureaucracy that dishearten and discourage talented people. At best, people are being forced to work below their capabilities. At worst, people are lost to another company that doesn’t include such roadblocks.

On the other hand, a good process can, ideally, bring a team to a hyper-performing state quickly and keep them there, while poor processes seem to only be good for shielding people from the ugly truth. Processes, policies, methodologies, and frameworks that emphasize value and seek to eliminate waste tend to bring out the best in people. The downside is that the best processes expose weaknesses within the team and force them to confront their demons. If the problem is the people are not skilled or committed enough then they may not be willing to put in the effort required to get the team to where they need to be. The best case scenario is the team members who are unwilling to change leave to free up the rest of the team to reach their potential, while the worst case is they stay and cause the team to drag and stagnate.

Neither of these seems to get to root cause, so let us consider the principles that form the foundation for people’s decisions and behaviors. When considering founding principles as the root cause, it is necessary to start with two assumptions. The first is that the people doing the work are genuinely doing the best they can with what they have. It may be somewhat altruistic, but I believe it is true for most people. The next assumption is that these same people are working with a process and in an environment that allows for and even encourages continuous improvement. Whether it’s explicit or not, people tend to adapt the way they work over time, based on their experiences and their guiding principles.

If my assumptions hold true, and my experience tells me they do, then those guiding principles that determine in which direction the process evolves are the most important factor in driving productivity, efficiency, and morale. The founders of the Agile Manifesto understood this. They came from various backgrounds exercising various forms of what are now considered Agile Methodologies. They did not define any specific process for success – instead, they defined a mindset, a paradigm, for approaching Software Development. They backed this manifesto with 12 principles, only one of which pertains to the type of people that are needed to be successful:

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

The only qualification they state is that the individuals be motivated. Surely some people are inherently more driven than others, but, for the most part, motivation is something that can be fostered by the culture and environment that the individual is operating in. The other 11 principles provide great insight into how those people should work as well as what should be done to support those people in their pursuit of high quality Software Delivery. If people have learned and accepted these principles then they will recognize how important and urgent it is for them to improve individually, not just as a team. It is not a character flaw to admit imperfection – indeed; it is the manifestation of character that one can admit to room for improvement.

The Agile Manifesto is not the only source of correct principles. There are many books and courses in existence that focus on this very subject. The whole premise of Lean Six Sigma is there are solid principles that can be applied in any situation to eliminate waste and reduce delay. I think Lean, Agile, and Product Development Flow principles are the most crucial to our combined success, but I recognize that there are others. What I would like for you to ask yourself is, “What are my guiding principles? When things get uncomfortable, how do I evolve the way I work?”

Why is this important? Because too often we pick up a new process hoping it will be our Silver Bullet, the solution for all our problems, the answer to all our prayers. But we adopt these processes without taking the time to understand the principles on which they were founded. As a result, we bend the process to fit what we are comfortable with and lose much, if not all, of the benefit the process could have afforded us. This mistake of adopting a process without adopting its defining principles is what I’ve referred to previously as the “Movie Version” of that process as opposed to the “Book Version”, and the book is always better than the movie.

Only by taking the time to understand correct principles will we be able to govern ourselves most effectively. As Blaine Lee said, “The principles you live by create the world you live in; if you change the principles you live by, you will change your world.”

Wednesday, May 1, 2013

Bottlenecks: the Enemy of Agility

I am the Release Train Engineer for one of my company’s first Release Trains. One of my early struggles when we first adopted the Scaled Agile Framework was understanding what the responsibility of the System Team was and how to concisely articulate it to others. That understanding finally came during the Quick Start event where I heard Alex Yakyma say the System Team identifies, manages, and eliminates bottlenecks. What a powerfully simple mission! I’ve since dedicated time to understanding and helping the team understand what that means, and this is what I’ve come up with so far.

First, how do you identify a bottleneck and what does it mean to be a bottleneck? Sometimes this can be rather obvious, but often it is difficult to separate the symptoms from the root cause. This can be a process, practice, culture, etc. I have come up with a process to help myself and my System Team identify bottlenecks.

First, envision what it would be like if we could deploy to Production a dozen or more times per day. Not that we would, necessarily, but what would it take to be able to roll new functionality to Production the same day we get the request? Second, document our current process and lead time from conception to Production. Third, identify the gaps between our current process and the ideal of Continuous Delivery.

If you find yourself defining symptoms and not the root cause, start using a Lean perspective and start asking “Why?” For example:
“It takes too long to get a package to Production once it’s been approved.”
“Why?” “Because we have to find someone who has the bandwidth to get it deployed.”
“Why?” “Because we do not have an automated deploy process in place.”
“Why?” “Because our application runs on WebSphere in a Mainframe environment, and we can’t set up auto-deploy until it’s migrated to a Linux environment.”
Here we have identified the primary bottleneck – the environment on which our application lives in Production – by asking 3 “Why”s. Expect to ask as many as 5 “Why”s before getting to root cause.

Next, we need to time box the bottleneck. This basically means you’re going to work with what you have for the time being and basically “deal with it”. This is a temporary phase until you are able to eliminate the bottleneck. You should have a timeframe for how long it is acceptable to manage a given bottleneck and hold yourself to that timeframe. You may not always meet your goal, but time boxing is the first step in giving the bottleneck some form of finality.

Last, we need to eliminate the bottleneck. The easiest solution is to just do away with it – stop doing it outright. This is also usually the least feasible. The best solution is usually automation, simplification, or combination. If you can automate it, automate it! This way you’re not diminishing the task, you’re making it take less time. If you can’t automate it, see if you can apply Lean thinking and simplify it somehow. Can you get what you really need with less? Agile encourages just-in-time and just-enough to limit the amount of waste we allow in the software development process. One of the backing principles to the manifesto states “Simplicity – the art of maximizing the amount of work not done – is essential”. Finally, if you can’t automate or simplify the task, see if you can combine it with another task to “kill two birds with one stone”. Pair Programming, an XP practice, is a great example of this – you’re essentially rolling your development, code review, and knowledge sharing all into one activity that typically doesn’t take any longer than development normally would.

Once you’ve eliminated one bottleneck, repeat the process indefinitely. Kaizen mindset tells us there’s always room for improvement and it’s always urgent that we improve. By all means, take the time to acknowledge and celebrate your improvement, but don’t get complacent.