Archive for the ‘Agile & Lean’ Category

Things happening that are good for my ego ;)

Agile & Lean, Facilitation, Photography, Presentation, Travel | Posted by Doc List
Nov 30 2015

Tomorrow (Tuesday, December 1, 2015) I will be featured in “Photography and the Art of Facilitation“. It’s a virtual, online event in which I get to talk about two of my favorite things – Agile and Photography – via one of my professional areas of expertise, facilitation.

On Sunday, December 6, 2015 I leave for Spant! in The Netherlands. On Tuesday, 12/8, I’ll be delivering a keynote at the Continuous Delivery Conference. My topic is “Continuous Delivery requires Continuous Communication“.

Coming up next year I’ll be at a number of conferences and conventions in both the Agile and Photography worlds. I’ll also be teaching more classes in Austin, including my well-received class on creating composites in Photoshop. Here’s a recent example.Amanda at the Prison

For those of my readers who are not uncomfortable with some nudity (“appropriate” nudity – no genitalia and no nipples showing on women), I’ve been busy this year with a passion project called the Austin Bodies Project. It’s primarily focused on celebrating fitness and the human body. It’s had an excellent response, including at the exhibit I had at the Gallery at the Ground Floor Theatre. If you are so inclined, can scroll back to August to see images of the exhibit.

In January, I’ll be volunteering at the Professional Photographers of America (PPA) annual convention called ImagingUSA in Atlanta. At the same time, I’ll get to learn from some top professionals, see the outstanding images that received merits* during this year (including mine), and hang out with some of my photographer friends.

In between all of this, I continue to work as an Agile Coach and Trainer, and as a photographer. I’ve got some weddings coming up, more work on the Austin Bodies Project, completing my application to be a PPA Certified Professional Photographer, and of course there are the holidays.

I’m crying

Agile & Lean, Musings | Posted by Doc List
Jun 17 2015

Read this first:

I love these women. I have loved working with them. I learned as much as they did, I think, as we explored applying the values, principles, and practices of Agile Software Development within the HR department at Gap Inc.

It saddens me in so many ways that this team is being “redeployed”. This project shows such promise, both at Gap and for the HR profession.

When I’m not so sad, I’ll write my thoughts about what we’ve learned and why this went the way it did.

For now, I’m being sad.

Amazingly Agile

Agile & Lean | Posted by Doc List
May 07 2015

I’ve been privileged (yes, seriously) to work with a group in the HR department at Gap Inc.

Yes, the HR department. Not software development/IT/technology, HR.

And it has been amazing. They built a team.

Going back to last year when this started, they had me come in to do Agile basic training. It was a three day class, and at the end of day one they said “While this might be very relevant for people in IT, it’s just not resonating with us. Could you do it differently?” At which point I threw away the Powerpoint I’d been using, found out from them what topics they were interested in/concerned about, and made it up as I went along.

They loved it!

The following week was aimed at doing some coaching, working with their pilot team. When they introduced me to that pilot team, there were Directors, Senior Directors, a Vice President, and a couple of Senior Managers. Lovely people who know a lot about the subject and care about it.

But they were the wrong people. They had too many responsibilities, too many demands on their time and attention, and would have been hard pressed to get things done. I told the Executive Sponsor this.

And so they built a team. They agreed to identify people who could be dedicated to the project. In some cases they searched the rest of the organization to find the best people to fill out this team of five. One of the members of the team has never been in HR. This process took months. I patiently-but-eagerly awaited the results, and finally got to meet the team in the last week of March.

This is a remarkable team. Their tenure at Gap ranges from 25 years to one year. Most of them have been in HR for a significant period of time. All of them are smart, personable, committed, and eager to learn. Oh – and they’re all women.

I’ve been working with the team, on and off, since the end of March. I’ve spent one week, two weeks, one week. We have a team room. We’ve done much of the usual kickoff/inception stuff. This team has struggled and learned and demanded more and more from me to satisfy their desire to learn. We’ve explored Scrum vs. Kanban vs. Scrumban (and – at least for the moment – settled on the latter).

They’ve tried cards+stickies and a few different electronic systems for managing the backlog and workflow. It’s been a whirlwind and an adventure.

Here’s one of the things that excites me the most: they’re making everything they do public!

Take a look at their site. I’m so impressed with what they’ve done, both as an agile team and in publishing the experience and their work.

It’s f’ing awesome! I’m so proud.

Walking in sync

Agile & Lean | Posted by Doc
Aug 29 2013

At the client facility where I’ve been doing coaching and facilitation/training, they have large, long corridors floored in tile.

The other day, as I was walking out – about the equivalent of three city blocks – I heard footsteps behind me. Click click click of hard heeled shoes. I glanced over my shoulder and saw a woman walking in the same direction I was going. No big deal.

I faced forward and continued walking.

I heard the sounds of another person coming into the main corridor from a side corridor. Now the sounds went

Clickclick click click click…click clickclick click click clickclick…

As I listened it changed to

clickclick cliclick clclick click click click click

Just in case that’s not clear (LOL), what happened was that these two women started to walk in sync. It continued for a few more seconds until it was clear that they were walking¬†perfectly in sync with each other.

meetingI turned to look and saw that they were not together in any way, and were walking on opposite sides of the corridor.

I blurted “You synchronized!” They looked at me, looked at each other, and laughed.

Now let’s consider the larger implications of this simple experience. Two people who apparently did not know each other, organically beginning to move in sync with each other.

How does this play in teams? (You knew I was going to go here, didn’t you? ūüėČ )

Consider a group of people who may or may not have worked together before, who have different work styles and rhythms, who see things differently and understand things differently. Throw them together in a modest sized room, give them some guidance on how they might work together, get them started, and coach and guide them. Mightn’t they also begin to walk in sync?

Walking in sync doesn’t mean that they become identical. The two women walking down the corridor behind me were not the same height, were no doubt thinking about different things, were carrying different things in their hands, wearing different shoes, and so on, and yet¬†they naturally fell into sync with each other. Their differences remained, and yet they began to “work” together organically.

This is what we expect to see on Agile teams: organically beginning to work in sync, to develop rhythms and patterns that belong to the team, as much as to the individuals. We see this on high performing teams consistently.

Are you fighting the rhythm or letting it flow through you?

No one Agile

Agile & Lean, Musings | Posted by Doc
Aug 28 2013

What’s the right way to do Agile?

Thinking differentlyIs Kanban Agile? Or is there Agile and Kanban and Lean and…?

Is iterative harder than Kanban or vice versa?

These questions and more seem to lead to organizations making statements like “this is the way that WE do Agile!”

I don’t object to an organization choosing an approach, unless they choose from a position of ignorance or confusion or both. And that’s what I see a lot.

There is no one way or right way. Even within a single organization, there might be variations that make sense.

There is no Agile Cookbook. There’s a pantry, a refrigerator, a stove, and a bunch of hungry people. Go figure it out.

Agile is people, pure and simple

Agile & Lean, Musings | Posted by Doc
Aug 27 2013

In the community of Agile practitioners and aficionados, there is frequently a focus on practices. Developer practices. Tester practices. Leader practices. Ceremonies and rituals. A lot of what we do.

Those who have passed the Shu level are aware that this is only a small part of what has led to the success of Agile.

Consider the value statements (

  • Individuals and Interactions over Processes and Tools
  • Working Software over Comprehensive Documentation
  • Customer Collaboration over Contract Negotiation
  • Responding to Change over Following a Plan

The first and third are clearly about people. The last is also fundamentally about people – mindset, attitude, and management.

Also consider the principles ( I’d say that seven of them are clearly about people, and two others clearly have implications about and for people. That’s 9 out of 12.

This says that the seventeen men who collaborated on the Agile Manifesto saw people at the heart of everything. As do I. I don’t think that has changed in the twelve years since they penned this historic document.

Coaches coach people.

Trainers train people.

Many of the many practices are obviously about people. For example:

  • retrospectives
  • daily stand-ups/scrums
  • planning
  • estimating
  • pairing
  • co-location

Quite a number of the others are also – directly or indirectly – about people.

When you get right down to it, the practices are Processes and Tools.

Think about the people.

Are you an intelligent fool?

Agile & Lean | Posted by Doc
Nov 20 2012

Any¬†intelligent fool¬†can make things bigger and more complex… It takes a touch of genius – and a lot of courage to move in the opposite direction. ¬† ~Albert¬†Einstein

In the Agile community, there are many values and principles that relate to this. One of the twelve principles that comes from the authors of A Manifesto for Agile Software Development (a.k.a. The Agile Manifesto), is this:

¬†Simplicity–the art of maximizing the amount¬†of work not done–is essential.

When I’m facilitating workshops about Agile and this comes up, the first place people go is this: “So if I understand this correctly, the less I do the better, right? So doing nothing is perfect, right?!?”

After everyone has a good laugh, we get down to really trying to understand this. Is it profound or simplistic? Is it meaningful or just noise? What the heck did those seventeen guys mean by this?

I had an interesting discussion with someone just recently. His argument was that the word “maximizing” should be “optimizing.” I can’t argue with that. I wasn’t there and I don’t know what the authors were thinking, but clearly “maximizing the amount of work not done” could readily be interpreted to mean zero.

wonderingLet’s consider what they might have been thinking and what that implies for the members of a project team. We have to begin with the context that a certain amount of the Manifesto’s authors’ drivers were reactions to the classic/traditional Waterfall approach in which as much work as possible is done up front: requirements, system design, database design, visual design, detailed functional design, test plans, project plan and Gantt charts…

I’ve talked with groups around the world about this. When I ask them how much time they spend before writing a single line of code – doing all the up front stuff – I’ve gotten answers that range from 25% of the total time to¬†more than 75% of the total time!¬†Wow. That says that in one of those organizations a two year project might not see a single line of code written from somewhere between¬†six and eighteen months!¬†Think about the investment, and how it plays into the return on investment (ROI).

Put it in dollars. If a project is estimated to cost $2M, that would mean that somewhere between $500K and $1.5M would be spent before there was anything to actually work with or experience. No code, nothing functional, no idea if we’re on track or not.

A typical agile team writes and works on stories that address the work – the functionality and features – in vertical slices. As a result, if we consider the underlying database, those teams only add structure to the database – tables and columns and indexes and such – that are sufficient to support the current work item. Those teams also only do sufficient visual design – page/form/screen layout, widgets, details – as is sufficient to support the current work item. Those teams also write only enough documentation to satisfy the real needs of the users, operations groups, and others, rather than everything they can possibly think of. And they only add enough documentation to reflect the work they’ve actually done.

What this leads to is another of the twelve principles:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 

So now we have an approach that emphasizes¬†simplicity delivering¬†working software on a regular basis. Let’s compare this to the numbers I played with above. A two year project leads to working software that the stakeholders and users can experience in weeks, rather than six to eighteen months. It also means that that working software has been produced for less that $250K – half the cost that would have been spent before writing a single line of code, according to various sources.

I am not calling advocates of Waterfall or other approaches fools. There are many outstanding examples of Waterfall success. I am saying that perhaps we should consider whether there’s a way that might be more effective. I am saying that Einstein and the authors of The Agile Manifesto¬†might just have had something.

Simplicity, genius, courage… good words.

The Subtleties of Language

Agile & Lean | Posted by Doc
Aug 20 2012

Are you an agile coach? A Scrum Master? An Agile Project Manager?

Then I have some questions for you…

  • Do you¬†run meetings or¬†facilitate meetings?
  • Do you¬†drive your project, or do you¬†support and enable your project?
  • Do you¬†assign work or do you¬†track and report progress?
  • Are you¬†in charge or do you¬†serve?

I’ve run into quite a number of folks who have not yet figured out that the language they use both¬†reflects their thinking and¬†communicates their mindset.

I encourage you to consider your role and your purpose, and then consider how your language – both thought and spoken – reflects and affects.

Agile as Exercise

Agile & Lean | Posted by Doc
Aug 06 2012

I made a new friend at the gym. His name is Joe. Joe and I have been seeing each other at the gym for a few years, and finally introduced ourselves. Typical male gym behavior, I think.

We got to talking about our lives, and I learned that Joe is not in the world of software.

Joe asked me what I do outside of the gym, and I started to tell him about Agile Software Development. He had no clue what I was talking about, so I started looking for an analogy that would be meaningful. As I often do when searching for ideas and words, I looked around me.

Here’s what I realized, as I tried to explain Agile Software Development to Joe.

Waterfall exercise: decide exactly what I want to look like a year from now, prepare a detailed exercise and diet plan that covers every day between now and the end of the year, work on one muscle group at a time (imagine building arms, then legs, then core, then back, then chest,…), and at the end of the year, hope that I have a well balanced, proportional, healthy, attractively sculpted body. Resist change, follow the plan as closely as possible, and hope that it all comes out right.

Agile exercise: well, this is what most of us really do. Plan a week or two (or even four) ahead in some degree of detail. Work on our whole body during each – umm – iteration. Adapt our workout and our diet to the progress we’re making, and as we discover what is working well and what is not working as well. Continuously improve our fitness, our health, and our understanding of exercise and how it affects us. Commit on an ongoing basis, seek input from our “stakeholders” (my wife, my children, my friends, my gym friends), keep learning by reading and talking and such, and consider it always a work-in-progress. Engage a coach (trainer) when I feel I need one. Share what I’m learning with others.

Which sounds more natural to you?

Announcing my new position at Neudesic

Agile & Lean, Career, Musings | Posted by Doc
Sep 26 2011

I’m thrilled to share this with all of you. As of the 12th of this month, I joined Neudesic, which is based in Irvine, California and has offices in a number of cities around the United States and in India.

Neudesic is a Microsoft National Systems Integrator and Gold ISV Partner with a proven track record of providing reliable, effective solutions based on Microsoft’s technology platform. Our technical and industry expertise empower enterprises to enhance their technological capacity and respond to business opportunities with greater efficiency.

I get to work with my good friends Ted Neward and Simon Guest, both of whose judgement I respect.

My title is “National Agile Evangelist”. That means I’ll be focusing on how we can be more effective at developing and delivering our services through the use of Agile, Lean/Kanban, and whatever methodologies suit. I’ll also be focusing on how we assist our clients in adopting these practices and principles to the betterment of their organizations.

The process going from day one (“your position is no longer being funded” at TW) to making the decision to join Neudesic was thoroughly enjoyable for me. I got to spend time with people I knew and liked, people I didn’t yet know and discovered I liked, and also to learn about what’s going on in the Agile Coaching space in the United States.

For each of you that contributed to the journey, please accept my gratitude.

I hope I can do the same for others.

%d bloggers like this: