Understanding the “Why?”

"Would you tell me, please, which way I ought to go from here?"
"That depends a good deal on where you want to get to," said the Cat.
"I don't much care where –" said Alice.
"Then it doesn't matter which way you go," said the Cat.
"– so long as I get somewhere," Alice added as an explanation.
"Oh, you're sure to do that," said the Cat, "if you only walk long enough."

I've written a couple of blog posts on understanding the principles of Agile, the “book version”, as it were, in order to achieve the success that is associated with Agile. If you've been in the Agile arena for any significant amount of time, you know there are a lot of disagreements as to the “How” of Agile. There are many different methodologies, frameworks, tools, and practices out there to support Agile teams. Some believe this is because people simply disagree on how to best implement Agile and, in some cases, this is true. Others understand Agile was never intended to be “One Size Fits All”. There are many options because there are many teams and each team must determine what solution works best for them – and evolve that solution over time in the spirit of Continuous Improvement.

This means you cannot determine “How” you want to implement Agile until you understand the needs of the team. “We need to have a Daily Scrum.” Why? If you can’t answer this then it’s not going to bring as much benefit as it should. If you understand the Daily Scrum as a touch-point to align across team members; identify risks and dependencies the team is encountering; and jump-start communication that will occur throughout the day then it becomes a stale and stagnant status update meeting.

My recommendation to Agile teams, and all human beings for that matter, is to not adopt something without understanding the “Why?” behind it. True Agile teams do not do things for the sake of doing them. They do them for a reason and nothing is sacred; if a tool or practice outlives its usefulness then it must be “put out to pasture” so as to not get in the way of the team’s continued growth. By regularly re-evaluating the usefulness of your current implementation, you also get the benefit of being open to new things. No matter how good your team is, they will never be as good as the team they could be.

Conversation

Many Scrum practitioners don't realize that Scrum did not invent the idea of User Stories - XP (eXtreme Programming) did. They are, however, often familiar with Ron Jeffries' "3 C's of a User Story", namely Card, Conversation, and Confirmation. The more I train teams on User Stories, the more convinced I am that the Conversation aspect is the most important of the three, and it is applicable to all things Agile, not just User Stories.

I recently facilitated PSI Planning for my area's Agile Release Train (Potentially Shippable Increment). I’ve noticed that, with each new PSI, the teams become more concerned with extensive pre-planning. They try to get more out of the meeting by doing as much of the actual planning before arriving at the meeting. Unfortunately, they do not understand that the primary reason for PSI Planning is not to generate a plan as much as it is to have conversations. Teams must communicate and align with each other and their customers. They must examine their work to determine what dependencies and risks are inherent in the work so that they can communicate, manage, and mitigate them as much as possible. This process happens to produce a better plan, which is why we do it. However, those who come to the event with pre-determined plans often find they must be reworked or scrapped altogether.

Rework manifests itself as delay, and delay indicates waste. Agilists hate waste. In fact, an Agilist’s views on waste and rework can be found in the 10^th principle that accompanies the Agile Manifesto: “Simplicity – the art of maximizing the amount of work not done – is essential.” How do conversations help prevent rework? If we talk before acting then we get a better sense of the truth, established in an environment of shared context. Conversations mean multiple perspectives, which bring difficult questions and challenge our assumptions. They force us to produce something as a group that is better than could ever be produced in a silo. They reinforce the paradigm of “just enough, just in time” instead of “big up-front”.

Once I realized that conversations are integral to Agile, I began to review the tools and practices within Agile, specifically Scrum, for conversations. All of the prescribed ceremonies – Daily Scrum, Sprint Review, Sprint Retrospective, and Sprint Planning – center on team conversations. Pair Programming and Test-Driven Development are XP practices that rely heavily on communication, both within the development team as well as between the developers, testers, and customers. A good Scrum Master helps the team most by facilitating conversations, and the Product Owner’s backlog is meaningless if they don’t ensure the team understands the work. There are conversations baked into literally every aspect of Scrum!

Conversations are often overlooked because people do not view simply having the conversation as an objective in most cases. They focus on the stated outputs: plans; acceptance criteria; status updates; confirmation of stories completed; etc. Consequently, it is not uncommon for teams to find alternative means to deliver these results without the “overhead” of the conversations. They rely heavily on tools and individual efforts to maximize their time without hindering the team with human interaction. They may, at first, feel an increase in productivity as the perceived burden is lifted. Yet, inevitably, they find themselves struggling to deliver quality quickly and do not understand how Agile could betray them so. Hopefully they have a good Scrum Master or Agile Coach watching them adapt in the wrong direction that can have them take a step back so they can see the error of their ways. If not, it becomes easy to blame their frustration on Agile and revert back to their comfort zone of more “traditional” methodologies.

As a safeguard, I recommend teams, and especially Scrum Masters, go back to their roots frequently to make sure they’re staying true to the founding principles that make Agile methodologies so great. Remember that “business people and developers must work together daily throughout the project,” and that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Don’t just blindly follow a framework or practice; instead, try to understand why you are asked to do things a certain way. If the purpose that you perceive is not aligned with the Agile manifesto and its accompanying principles, you’re probably wrong. Acknowledge your failure, “Fail Fast”, and change your approach so that it fits the Agile paradigm. It may seem counter-intuitive at first, but it will pay off in the long run.

People != Resources

Within my area, I've become famous for correcting people when they say "Resources" and mean "People". I work hard to get people to think of each other as human with a unique skill-set and personality, not interchangeable cogs in a machine. When people start complaining about a "lack of resources" I ask them to make a shopping list and I'll pick some up from the store.

Apparently, my message is getting through.

The other day I was in one of the rooms our teams work in and saw this on the whiteboard.

I thought, "Wow, I really got through to someone!" Then, I saw this underneath that:

So not only do they understand that people are not resources, they point out an example of what would be considered a resource. Then, to drive the point home, I found this:

It's true, they're not! What I love most about this is that I didn't write any of this - members of my team saw the opportunity to share a message that they had bought into because they saw the value in treating each other as people, not just resources!

Finally, a bit of nerdy humor to finish this off. What else would you expect of a bunch of geeks? :)

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.”

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.

Agile: The Book vs. The Movie

I’ll be the first to admit that I’m a pretty big bookworm. I also love to go to the movies, which is less and less frequently now with young children at home. It’s an all too often occurrence for me to read a book and, as I see the images play out in my mind, think, “This would make a great movie!” Of course, that sentiment occasionally becomes reality and I find myself leaving the theater thinking, “The book was so much better than the movie!” The movie may even be good. It may be the best movie I see that year. But the book is invariably better.

I see teams, both inside my company and out, that struggle with making Agile work. Too often they get some basic knowledge, get really excited, and start forging onward without taking the time to continually research Agile best practices and innovations. It’s a stripped-down version of Agile, usually built on the roles and ceremonies only and not the principles on which Agile is founded. They’re taking all the action, but cutting out sub-plots and character development. It’s the movie version of Agile.

Over the past year, I’ve had several people express how impressed they are with how “by-the-book” my area is running Agile. And it’s true; we stay very true to the published recommendations that are widely accepted by the industry. We’re able to do this because the team has changed the way they approach software development. They have changed their mindset to one that aligns with Lean and Agile principles. They are flexible and embrace change because they know if something doesn’t work they can dump it after 2 weeks when the Sprint ends. This paradigm shift is essential for teams to be successful with Agile. It’s also the Scrum Master’s greatest challenge.

A team can run Scrum without a dedicated Scrum Master, but they are largely secretarial. They ensure the ceremonies are held and time-boxes are respected, but not much else. A dedicated Scrum Master is also a mentor and coach, with much of their time spent removing impediments; resolving conflict, hopefully in a productive way that results in learning and compromise; evangelizing Lean and Agile principles; and advocating XP and other technical excellence practices. This helps the team obtain and retain their “High Performing” status indefinitely. This is all made possible not in spite of all the change that is inherent in Agile, but because of it.

When it comes to Agile, I’ve “read the book” and “seen the movie” and, as with all other cases, the book provides a much richer experience. It might take longer to get through; it might take some imagination; and you might have to read it more than once. But the book is invariably better.

I'm back - and Agile!

I've taken a bit of a hiatus from blogging for quite a while, and I'm wanting to get back into it. To be honest, I've been blogging quite actively for quite some time, but it's been on internal blogs on my company's intranet. However, I've got insights that I want to share outside just the scope of my company, so I'm taking my thoughts that don't expose any trade secrets and publishing them here!

In the past, my blog posts have been pretty technical, and they will continue to be - to an extent. My role has shifted over the past several years from Software Developer to Agile Coach and Scrum Master. If you're not familiar with those terms, I basically am trying to improve the way we deliver software by changing the way we approach the work. You can read a little by Googling "Agile Software Methodologies" or "Scrum Software Methodology", or you can check out the Agile Manifesto or the Scrum Alliance websites.

So that's about it for now. I'm going to be doing some housekeeping on the blog and will start posting next week! I can't guarantee how frequently, but I'm shooting for at least once a month. Please leave your comments to let me know what you think!

Why Google+ Won't Work

The last time I posted on this blog was to announce my eager anticipation of the life-changing Google Wave. Here we are 2 years later and Wave has totally replaced e-mail! Right? Wait, what? Support for Wave by Google is about to disappear and all further development will be done by the Open Source Community? That doesn't sound like a widely adopted revolution...

Google Wave had some great ideas, but it struggled with a lack of a simple, user-friendly interface that was both quick and intuitive. It tried to do too much too fast in a Twitter world.

Now, here we are. Google+ has been announced and released to a small group of demigods who hold their currently obsolete invitations ransom to the rest of the world who is dying to see how it works to they can tweet about it and let all their Facebook friends know how cool it is. And therein lies the problem. We've already chosen our drug of choice, and it's going to take an incredible first-time high to hook us enough to switch for good.

Google+ might have had a chance if it came out guns blazing, showing everyone what it could do. It could still have retained a semblance of exclusivity by using invitations - you can only invite 50 people a day to Google+. Of course, with that amount of invitations going out it would blow up pretty quickly. Then, assuming it had something really new and fresh to offer, it might keep its head above water long enough to win over a non-insignificant percentage of the Internet population.

Instead they're showing everyone what they've got without letting anyone use it. My prediction: before they can get a toehold on the Social Network market Facebook will identify the gems of usefulness out of Google+, implement those features themselves, and Google+ will be left on the side of the road like so much picked-apart carcass. I'm serious about this. Go to Google+, find your favorite new feature (aka one that's not already in place on Facebook), and see how long it takes for it to show up on Facebook. I bet the best ones are there before Google+ really opens up to the public.


Google was not the first ones to do online search, but they did it best and got in early enough to win the masses over. From where I'm standing, they're too late in the game and not hitting it hard enough to win this battle. I hope I'm wrong - I love Google - but I don't think I am.

Waves, Tweets, and the future of Communication

I'm a bit of a techie guy. After all, I'm a programmer by profession. So I sometimes feel that it is my obligation to be up-to-date on Tech-related stuff. I've known about Twitter for some time, but I've put off getting an account until yesterday. I know, I know, I'm a little late getting on the band wagon, but I'm on it now and that's all that matters, right?

Anywho, I was pushed over the ledge by watching the Google IO video unveiling Google Wave. One of its pioneers, Lars Rasmussen (he and his brother brought Google Maps to the world), mentioned Twitter as "Everyone's favorite Social Networking site", or something to that effect. That's when I realized that it wasn't just about me, it was about being true to my profession and my generation. Cheesy, I know, but it's my justification.

Okay, back to Google Wave. It is hard for me to contain my excitement about Google Wave!!! I CANNOT wait for the public beta release! :) I know it's a little long, but I really think that everyone should check out the demo. It will revolutionize communication as we know it!



By the way (I know, I spelled it out - weird), if you're curious about the terminology associated with Google Wave, check out the explanation on Wikipedia. It's pretty interesting!

Tooting Your Own Horn

I’ve always been told that it’s a bad thing to “Toot your own horn”. This colloquialism typically refers to bragging or boasting. But if you view your horn as your accomplishments, I’ve come to the realization that you have to toot your own horn, or who will?

Obviously there are those out there that would be willing to give a toot or two. There are family members, close friends, and respected colleagues that would be willing to speak up at a moment’s notice. What they likely won’t do is go out of their way to talk someone else up without any nudging or coercion.

There are moments in life, plenty of them, actually, where it is perfectly acceptable – perhaps even vital – for “self tooting”. It just has to be done carefully. For example, I feel I’m due a promotion at work, especially since they took my last one away (they actually just eliminated the position altogether – my compensation was unaffected by the stripping of my title). Now, what I can’t do is bust into my boss’s office, guns blazing as it were, demanding the promotion that is rightfully mine whilst my bards and minstrels catalog my glorious accomplishments and sing accolades to the wonder that is me.

I’ll give you a moment for that imagery to set in.

This is what I can, and intend, to do. First, I’ve been keeping track of the things that I have done to benefit the company. I have participated in and even led minor projects successfully that my internal customers are now benefiting from. Next, I will sit down with my manager and outline these accomplishments, emphasizing both the benefit to the company and the translation to job skills that are required by the position I am seeking.

You may ask, “Shouldn’t your manager know all that already?” The reality is that, due to exceptional circumstances, I’ve spent 3½ months under my first manager, 1½ months without an official manager, 3½ months under my second manager, and now ½ a month under my third manager (who I will likely be reporting to for a while to come). However, even if I’d have had the same manager for the past 9 months I would not expect my manager to just know that I feel I’m ready for a promotion and why I believe I deserve it. Repeat after me: “If you can back it up then it’s not bragging. It’s a dissertation.” I just have to make sure that I stick to supporting my thesis or it might turn into bragging. If I can meet with my manager and engage her in open, honest dialogue, then we can at least get on the same page. But if I don’t “toot my own horn”, she’s not likely to hear anything.