Transforming to Agile – The “Easy Button” of Collaboration and Cultivation Cultures

October 31, 2012

As I explored in my last post, being agile is about transformation at an individual and organizational level, going deeper than simply adopting frameworks and practices. And depending upon your present organizational culture, agility will be a larger change for some organizations than it will be for others.

The reason for this is that organizational culture is defined by what the organization believes it needs to do in order to succeed, which translates into a specific mindset and a preferred way of operating. And while there usually is a dominant culture, keep in mind that traits of other cultures will most likely be present.

In this post, I’ll look at two culture types that more readily support agility than the other two – as those cultures are defined by William Schneider in his book The Reengineering Alternative: A Plan for Making Your Current Culture Work.

The two cultures covered in this post are the Collaboration and Cultivation cultures.

Assess Your Current Organizational Culture to Gauge Your Agile Adoption Effort

October 24, 2012

According to the most recent State of Agile Development Survey by VersionOne, the largest barrier to further agile adoption is the ability to change organizational culture. I believe the real question of the day centers on adoption versus transformation and how transformation can be a large cultural shift.

Mike Cottmeyer explored the issue of adoption versus transformation in a 2011 post, Untangling Adoption and Transformation. Mike’s epiphany was that adoption is focused on doing agile, concentrating on the practices that we put in place, whereas transforming is about being agile, which is all about leadership, understanding yourself and undergoing a personal transformation as a “precursor to agile software development.”

I agree with Mike, there is definitely a difference between adopting agile and being agile. That’s not to say that you won’t improve your current situation by adopting agile practices. Pair programming and Test-Driven Development are examples of technical practices that you can benefit from. Adopting Scrum as a product development framework gives control of the workday back to the employees, which should improve morale as a result.

However, Scrum and technical practices support agility, but they don’t make you agile. Practices get you started, but they only scratch the surface. Being agile is about going deeper, about viewing and approaching work that is a transformation change at a personal and organizational level.

Don’t Push Yourself

October 17, 2012

A fundamental change with lean and agile thinking is the concept of pulling work versus pushing it through a work system, whether that system is that system of you or a work environment comprised of many individuals. All too often we subscribe to notion that we must “push ourselves” to produce, to hit a pre-defined target. This sets us up for failure, particularly with complex knowledge work.

Problem #1 in using a push mindset is that we make a commitment to an up-front guess (estimate). We should be committing to the work that needs to be performed, not the estimate. The estimate is simply a gauge to inform us about the approximate size of an effort, but it doesn’t anticipate the inevitable extra work that inevitably shows up. A common countermeasure is to anticipate by buffering the estimate, which can lead to the next problem.

Problem #2 occurs when managers review the estimates. All too often they start assessing the size of the work should be – based on what is known – balancing that work with the perceived capacity and what they feel a good utilization rate should be (which tends to be on the high, optimistic side). After some “negotiation,” estimates are trimmed and the team is asked to commit to “their” estimates and the target date. (You can do this to yourself if you misjudge your own capacity and plan for too high of a personal utilization rate.)

Problem #3 is that extra, unanticipated work will find its way into those predefined tasks. This will cause tasks to go long, and the schedule will become challenged. Capacity problems are revealed! Work piles up, and managers (or yourself as the manager of you) typically counter by demanding overtime, effectively punishing the team for not meeting their “commitments.” Overtime and the negative connotations about the team failing to meet its commitments builds a contentious , us versus them relationship that can in turn lead to other undesirable behaviors, such as cutting corners so that the team can get a project “back on schedule,” despite the fact that these actions will have serious, long-term repercussions.

Leverage Personal Kanban to Introduce Lean and Agile to Your Organization

October 10, 2012

In my last post I described how I’ve recently implemented Personal Kanban to help me be more productive. I created my personal backlog, identified recurring tasks, and mapped out my value stream (the flow of work from beginning to completion) on my Personal Kanban board, following the advice I found through some quick research.

I find the term Value Stream to be particularly important; if you are undertaking some task, the underlying assumption is that there is value in your doing it. The question is: What provides you with the greatest value?

Personal Kanban helps you to assess your actual work, to visualize your own investment of time to help you determine where you are wasting energy, such as expending too much time and effort on urgent needs while those important, high-value tasks remain starved for attention.

There is another way that Personal Kanban can help you. Long-term goals take time to achieve. And because they are long-term in nature, we need to break them down into a series of small tasks – small wins – to keep up moving and motivated. As Peter Sims relates in his book Little Bets: How Breakthrough Ideas Emerge from Small Discoveries, cofounder and the former chief creative officer of Electronic Arts Bing Gordon calls this smallifying.

Meaningful Work/Life Balance through Kanban

October 3, 2012

Like a lot of people, I face plenty of urgent demands each day – both personal and professional. And like everyone else, I feel overwhelmed at times by the continual onslaught of demands and requests for my time. Lately I’ve felt that I’ve been extremely busy, but not anywhere near as effective as I should be. I was feeling unsatisfied at the end of the each day (and week).

I wanted to do more than simply suck it up; to work endless hours to finally – which never happens – catch up. What I really needed to do was to get a grip. And this meant more than checking off tasks on a to-do list. I wanted to be both efficient and effective, addressing both the urgent and the important, to make sure that I gave myself those meaningful accomplishments – whether they are of a personal or professional nature – that provide us with that satisfied, rewarding life and career.

So what’s an agile practitioner to do?