Have a Question?


Contact us and we’ll respond promptly.


Selflessness

by Darian Rashid 4. June 2010 08:55

 

"Selflessness gives one center.
Center creates order.
When there is order, there is little to do."

 

From the Tao of Leadership by John Heider, adapted from the teachings of Lao Tzu

Tags: , ,
Categories: Agile Leadership | ScrumMaster | Agile Transformation | Culture | Process | Teamwork

Organizational Transformation Barrier: Corporate Security Policies

by Darian Rashid 28. May 2010 08:23

Series: Barriers to Organizational Transformation

 

The Barrier
This is the first post in the ‘Barriers to Organizational Transformation’ series and it is the Friday before Memorial Day so I thought I’d start with something light but important: Those corporate security policies that disallow openly displaying information on walls, hallways, etc.

 

The Effect
As you can imagine, the problem with these outdated and frankly useless policies is forbidding to put up any vital visual management tools (e.g., task-boards, burn-down charts, defect rates, etc.), architecture diagrams, meeting boards, etc. and have to erase everything from whiteboards at the end of the day.

I have actually been present at sites where we just got through getting the team bought-in and excited about the idea of transparency though visual indicators and information radiators, agreeing upon and constructing the visual information radiators and installed them and then promptly being asked to rip them down by security the VERY SAME DAY! This was not just a blow to morale, but set the transformation back since it was one of the pilot teams. Unfortunately, I see this barrier in almost every client I work with.

 

The Reason
The reason behind this policy is that they do not want vital information to be seen by someone on the outside, especially corporate spies. While I can understand this, consider the amount of security that needs to happen before someone can even get in, starting with a badge that has to be authorized by a guard or an electronic system. I have seen this policy enforced even when there were 3 separate locked doors standing between the would-be ‘spy’ and the information.

Consider a couple of things:

  1. Would someone who can breach physical security not be able to get to your wiki, most of which are available on the intranet w/o a username and password?
  2. Is the fact that John Q Engineer is blocked on task #3 on day 5 of the sprint actually useful information? Will your competition’s CEO look at that information and say, “My plan to take over the world is coming together nicely, now that John is blocked on task #3 ”?
  3. Even if it is a guest or a customer, would it really matter if they looked at that information?

 

The Solution
Fortunately, the solution to this, even in the some of the most rigid environments, is reasonable simple (compared to the other barriers, anyway). Meet with one of the managers (the highest-level manager you can get to) of the security group in your physical space and go over the use and importance of these information radiators with them. Explain to them what they are and why they are needed and why the information isn’t harmful and they will usually grant an exception. In many cases, there is an exception form that has to be signed by a manager or director within your group.

Sometimes they will ask you to obfuscate some of the information or ask that just a small part not be displayed or taken down and locked up when not being used. We concede to some of these, especially architecture. Many of those are easily resolved by doing what we need on the whiteboard, taking a high-quality picture (or set of pictures) and displaying them in a secured site.

I once had one of these meetings where they said everything is allowed to stay up as long as you write the codename backwards. We had to laugh at the fact that we have a codename for a codename. Like someone from the outside is going to look at it and say “utkubmiT? What’s that? Darn-it! My plans are foiled once more!” None-the-less, it was a small price to pay and we complied.

 

Do you have any war stories with this barrier? Please share. We’d love to hear them.

I Didn’t Learn to Drive by Reading the Manual

by Darian Rashid 25. May 2010 09:21

Series: Agile Transformation Anti-patterns

I remember that day like it was yesterday. The click of the camera, the awful picture, the waiting for what seemed like hours and finally, that moment where I was handed, still hot off the lamination machine, freedom, emancipation, liberation – or as you may call it, a driver’s license! That was one of the most memorable moments of my life (don’t tell my wife). And it was hard-earned! All those days of repeatedly practicing K-turns, parallel parking, mastering the art of the 4-way stop and just generally surviving driving in New Jersey! All those skills that we can now exercise in our sleep (but really, really, shouldn’t) weren’t as intuitive or simple back then. It took a lot of practice and more importantly, coaching when we were learning.

Even though I knew that Driver’s Manual inside-out and received only one question wrong on the written exam (which I still don’t know the answer to, btw), I would never dream of getting behind the wheel of the car with just my learner’s permit and a vision to one day own that 1983 Honda Civic. I needed a coach sitting beside me, working with me and guiding me as I was driving. It was nearly impossible for most of us to go directly from passing the exam to the road test. I needed that guidance and practice in my own car.

Getting a driver’s license is the same learning model as becoming a doctor or an Agile practitioner:

  • Training and reading build knowledge
  • Applying that knowledge so that the desired outcome can be repeatedly achieved is skill
  • Repeated application of that skill in different circumstances forms experience

This process, unfortunately, is lost on most sponsors who cause one of the biggest transformation anti-patterns: Coaching not necessary – the thought that one 2-day course or just reading some books will instantly create a set of Agile practitioners. It takes time, dedication, experimentation and most of all, coaching, from an experienced coach that is either in-house or external.

Would you trust a lifeguard who received her certification on the Internet based on an online exam and no practice? What about a surgeon who has never had any internships, residencies or any hands-on experience? Would you trust him to operate on you? I understand that a newly trained Agile practitioner isn’t going (usually) to kill anyone if they miss an iteration goal or their retrospective goes sour but the concept is still the same – getting results from an Agile transformation takes experienced practitioners. Training, no matter how good, will only build knowledge. Applying that knowledge so that the desired outcome can be repeatedly achieved is skill. Repeated application of that skill in different circumstances forms experience. One cannot go from knowledge to experience and one cannot build skills in the classroom. To achieve the desired results from a team, it takes time to nurture and grow them, and that includes coaching along the way.

Don’t get me wrong. I’m not out to say that agile practitioners aren’t bright and can’t apply what they have learned in the class or book within their own environment. But consider your unique environment – your corporate culture and the quirks that are yours alone, your current environment, infrastructure, leaders and their leadership style, organizational structure, incentives, and so on. There are so many parts to the makeup of an organization that sometimes it isn’t obvious how to apply what they have learned. A 2-day course (or even a 10-day course) cannot cover all possibilities. And what about scaling? The more teams there are (esp. distributed teams) the more the challenges the newly trained practitioners face. It gets overwhelming, especially for new practitioners.

In addition, please don’t misinterpret my views about classroom time. I have been an instructor for years. I love teaching and I will be the first to point out that classes and books are an essential start. They add the knowledge which is required to start the journey. However, it will never build skills. Application of that knowledge in your own environment will do that. And the more complex the environment, the harder it is to apply that knowledge. Coaching from someone who has done it before and seen many of the pitfalls the team may be headed for will work with them to navigate the rocky terrain, teaching them within their own context and arming them with the tools to apply that knowledge to make wise decisions. In essence, the coach’s job is to work themselves out of a job. Repeated application of that skill in different circumstances forms an experienced practitioner who, by the way, is your next coach.

Don’t try and save the cost of some coaching and try and get everyone trained instead, thinking those will bring about results. Instead, consider picking a smaller subset of the whole who can be trained AND coached in their own environments, who, because of the coaching, would come up to speed faster, avoid common mistakes and would ultimately coach the next generation. Consider what you may consider an expense may actually be an investment, which will pay dividends for years.

Follow us

Follow AgileEthos on Twitter       Follow AgileEthos' RSS Feed

Recent Posts