Then I went to Bank #2 and their bank machine prompted me if I wanted a receipt (which I said no) and they had a notification that prompted me to press continue when I had my deposits in the envelop and was ready.  The roller thingys started when I pressed continue.

So my observation is, how much operating cost does Bank #2 save in receipt paper as well as the process for refilling it?  Being a bank I will assume the process is heavy and costly to refill the receipt paper container in the machine.  I wonder how much Bank #2 saves over Bank #1 every year by saving paper and process in re-filling the machine.  How much extra power do those little roller thingys use on a yearly basis for Bank #1?

Many companies I’ve worked with as a consultant and regular ol’ employee have a hard time grasping the concept of constant improvement in small increments.  I’m usually met with “It’s useless to not do the whole thing…” type of mentality.  Companies that really get it know how to have Kaizen events and understand taking on small and incremental improvements yields great results over time.  The flip side is the perception of progress instead of actual progress because so many (and usually large) improvements are talked about which makes people feel good.

How do you approach improvements in your organization?

“The #agile community is too closed. We are doing intellectual incest, and congratulating ourselves for it.” ~@mhsutton #ACCUS“

I can understand and appreciate the comment, I’ve posted many times about how I think the Agile community is disconnected from the reality that organizations are going through.  Having said that, I’d have to disagree with the statement that the Agile community is too closed.

There are numerous conferences across the world, user groups, study groups, forums, open spaces and local events that are easily accessible to just about anybody who’s willing to learn.  The key is that people need to be willing to learn.  I’m happy that 2 people I worked with when I was consultanting are speaking at the Toronto Agile Tour this year and the reason they are is because they were exposed to what the Agile community offers and they jumped at the chance to get more involved.  They’re dedicated to improving their skills and they have a desire to learn more.

I think the Agile community is awesome.   For starters, look at all the free advice through blogs and forums people in the Agile community give.  Look at the free whitepapers and experience reports the Agile community dishes out.  Look at how people in the Agile community give their time to the community through open spaces and other local events.  Most importantly, the people I know and have tremendous respect for are not content with being mediocre and being around that mindset is infectious.  We challenge each other, we question each other’s statements, we challenge the status quo in the name of building better software and improving the quality of life by living the Agile values and principles.

While I can understand the statement about the Agile community being too closed, there is responsibility on the shoulders of those who are not involved in the community.  Events and information are so easily accessible, there’s no excuse for anyone who wants to learn how to build better software to get off their ass and go learn.  Mediocrity is a choice, people and teams have more control over improving themselves more than they think they do and those who are content with where they are will likely never really get what the Agile community has to offer.  I pay for my own training, I give my time freely to help people new to the community, I am never satisfied with the status quo and my mind is always open to learning something new everyday.

The Agile community is about what’s possible.  The Agile community is constantly innovating better practices for building better software and making work more enjoyable.  People I know in the Agile community are using their knowledge to improve education for kids or improving government or making work fun by using games to teach techniques for building better software.

The Agile community taught me how to value my own skills, how to appreciate myself for the skills and experience I offer and most importantly, the Agile community taught me that no matter how much I know, there is a whole world of knowledge I’ve only scratched the surface on.  I am deeply grateful towards the people I’ve worked with and learned from over the years and I feel honoured that many of these people who are thought leaders in the industry consider me their peer.

The Agile community is too closed?  In my opinion it’s not.  Everyone has a choice to improve them-self, with so many easily accessible Agile events and materials to learn from there’s unlimited avenues to explore.

Thank you Agile community.

That got my attention.

I’m a raging introvert so when I won’t shut up, it’s usually about something I’m really passionate about or something I think I know a lot about. One of the objectives I set for myself at PSL was to learn how to be a better listener. I felt I accomplished that, or at least made substantial progress, and rewarded myself with the muzzle award for knowing when to shut up.

I don’t want this post too be too long so I’ll skip the examples where I channelled the image of Johanna pounding her hand on the table to keep me in line. Needless to say, I was more aware of my disposition and sense of knowing when to shut up than I was before.

Over the last few weeks after coming back from Agile 2011, I felt like I ‘gave up‘ a little.  In retrospect, I started to slip back into old habits of telling and not listening which wasn’t really helping me or the people in my life.  

My boss had reflected this back to me during a recent one-on-one so I’ve had some time to digest the feedback. More specifically, I thought about our one-on-one conversation and how much of it was us talking ‘at‘ each other instead of communicating.  We started well and I gave up my new listening skills early on which I think was the cause. Having said that, it was a productive chat, I feel it could have been better if I had channelled Johanna’s table-pounding image in my head.

I started looking deeper and another lesson from PSL started becoming clear. If you want to change anything, start with yourself.  I started thinking about bad conversations (work and home) and what problems I was facing and what of my behavior or lack of listening was contributing to those problems.

Today I set out to take those lessons and apply them. During my first meeting I caught myself interrupting someone 3 times. I caught myself early which I was proud of. I also used what I learned from Declan and Bryan’s ‘Pull conversation’ session at Agile 2011 to have better conversations with the people in the meeting.  I hope it helped, I felt better. I suppose I could ask them tomorrow.

Here’s how I would sum up what I learned with what I tried today (and what I like to preach to others about!)

• It’s not about them, it’s about you. Once you understand yourself better, you will be able to interact with people better. I found MBTI very helpful in this regard.
• Change starts with you first. You can’t, nor should you try, to control or influence people. I am using ‘influence‘ in the negative sense of ‘tricking‘ people, not ‘influencing‘ in the sense of persuading people that your idea is the best.
• People are good and are doing the best they can with what they have, whether that be skills or external forces (ie: is a co-worker who you think is an asshole just somebody who’s a really passionate person or maybe they’re going through a divorce. You don’t know whats going on in their head)
• Listen to people by reflecting back what they are saying. Use questions like “I’m not sure what you mean, can you describe an example?” or “I interpret that as ABC, is that what you mean or did I miss the point?“. There are many ways to ask “pull” questions but the point is that you may process information differently than the person who is transmitting, try and understand where they are coming from so your ideas and thoughts can converge.
• I find this helpful, prepare for conversations ahead of time, especially if you are introverted. I need time to process information so my emotional response comes out first if Johanna doesn’t pound the table quick enough.
• Find a technique that will help you stay focused, like my example of Johanna pounding the table.
• Stop a conversation at the sign of trouble. I am still learning how to do this because dammit, I’m right and I have to prove to you that I am right! This is probably the weakest area of conversation skill for me.

Before this meeting I made a conscious effort to be aware of my state and how I was engaging in the conversation.  I also set some mental pointers about specific things I wanted to improve on.  One of them was not interrupting.  The other was staying engaged by making a note of my physical posture.  When I felt like I was dis-engaging, my body language gave me queues and I corrected it.  I’m sure this probably sounds nuts, but I ended up thinking “posture matters, sit up…” in my mind.

I’ve been struggling with a closing paragraph for a good 15 – 20 minutes.  If I could share one last thing from this post it would be that you are responsible for your personal development.  If you’re unhappy with the status quo, remember, It doesn’t need to be this way.  Change yourself first, you’ll thank yourself when you realize how good it feels.

As have many others, I’ve seen different interpretations of what Agile means to different people in different environments.   From my experience, people generally consider Agile to be a ‘state of mind’, a particular practice or a set of practices.  I worked with a team in the past that considered themselves to be ‘very Agile’.  They were Agile enough to have a 4 day sprint after a 2 week sprint because all the work couldn’t get done in time.   I’ve worked with teams that had development and testing sprints.  I’ve worked with teams that had programmers that would account for re-working bad code in any story that was going to require changes in those areas.

Does that describe what Agile is?

I dunno.

The interesting part of those 3 stories is that the environments and culture created those versions of Agile, for the lack of a better phrase.  The 1st team that couldn’t seem to finish work in any sprint thought they were really Agile.  They thought this because there was no impact to missing the sprint commitment.  It didn’t really matter when the work was done or when it was released.  Using ‘sprints’ was just a way to break the work into 2 week chunks.  I’d call that iterative, not Agile.

The 2nd team I mentioned was in a larger company with very strong functional silos that were stronger than the team itself.  Some call that ‘mini waterfall’.  I don’t know what I’d call it other than that was the best these guys could do at that particular time.

The last team I mentioned was one of the best teams I ever worked with.  They all got along well, they all understood the application from a technical perspective and a user perspective and most importantly, they gave a damn.  They were a passionate group of people who challenged each other and just liked doing what they were doing despite the constraints they had as a result of their environment.

So is Agile a state of mind?  A single practice? A set of practices?  A couple of years ago I wrote a post about how I learned organization culture is the most important aspect of becoming Agile.  That seems to still ring true for me.

To me, Agile is like the old Lexus slogan from the 90′s.  ”The Relentless Pursuit of Perfection”.  I went to the Toronto Agile open space this past weekend.  That’s what Agile is all about.  People giving up their free time and time with family and friends to share ideas and learn about something.  There’s something special about these people.  There’s something intrinsic that drives these people to be better.

You can’t package that up and install it into an organization.  You can, however, package up and install a set of tools and practices into an organization.

My Agile is the former, yours may be the latter.  And that’s ok.  Just be aware of what you and your organization is capable of and choose your Agile adoption path to align with your culture and values.

Michael Sahota taught me this trick, stop using the word “should” and I found that the message stuck.  ”Should” is the easiest way to removing all sense of responsibility for your actions or team conclusions.  When I hear a team member say “we should do X”, often the rest of the team nods and nothing gets done.  I just caught myself doing this.

A team member sent around a list of great testing webinars that are coming up and I started to reply via email: “That’s awesome, we should sign up for the xxxx…..”

I stopped myself before sending.

I decided to register for it and changed my reply to “I will sign us up for session xxx and I will be in the open space area with the projector for anyone who is able to join.”

Amazing how something so simple can be so effective.    ”Should” is often used with the best intentions, however that word doesn’t lend itself to creating actionable output.  Change “Should” to “I will” or if you’re not able to take action, change “Should” to  ”Can you…” and ask for help.

The problem isn’t the word ‘Agile’ and sorry Ron, the problem certainly is not that “people don’t do what we said”  What kind of elitist attitude is that?  The problem is the message coming out of the Agile community isn’t resonating with organizations that want to adopt Agile.  Organizations want to adopt Agile for a reason and most of the time we overlook that reason and jam a bunch of wishy-washy crap and a bunch of practices down their throat all the while wrapped in a message of “gee, you just don’t get it“.    While the Agile community has evolved and matured, “our customers”  largely have not.   The Agile community is full of fantastic forward-thinkers that have made huge strides in spreading Agile practices and I think the pace of that evolution has far exceeded our customers pace of understanding how to apply these concepts to their context.

I talked to a potential client today and asked him why they wanted to “go agile” and he said to do things faster and cheaper.  That’s his perception of the benefits of Agile and that’s ok.  I certainly don’t blame him for his opinion, instead I asked him questions to understand why he felt that way and what problems his organization is facing that led him to the conclusion that Agile was the way to go.   Most importantly I want to understand his situation and help him improve his organization.

When I first got into Agile, my first experience was with a company using Scrum.  A client came to me and said “we need you to build X, Y and Z“.  I thought this was a good opportunity to learn something new.  When I asked our “Scrum guy” how we can approach this project I was met with what I now know to be the usual rhetoric.  Write some stories, build some stuff, get some feedback and repeat until it’s done.

I had asked how we could come up with the time and cost for it so the client could get budget approval and was met with “uh, you just don’t get Agile….it doesn’t work that way“.   Now that’s just dumb.

Agile needs a context to be successful and oddly enough that context came at the same company.  My at-the-time boss had introduced us to the Rockefeller Habits and it immediately resonated with me.  Long story short, we used Scrum to implement the Rockefeller Habits.  The Rockefeller Habits helped set the business context and Agile was the ‘tool’ that got us there.  We used common sense and used the Rockefeller Habits as our guide, not Agile and the results were outstanding.  I recently talked to my former boss and he mentioned that’s just how they work now.  It’s not the Rockefeller Habits or Agile, it’s just how they work because it makes sense for their business and it’s getting results.

That’s what Agile is.  It’s taking data from your system and making smart decisions with that data based on your context.  We had no automated testing, hell, we had no QA people at the time and a bunch of bugs that WE tracked that NEVER generated helpdesk calls so what’s the point of implementing XP practices?  There’d be no value.

We were just a great mix of people with a shared goal, a FANTASTIC leader and we were willing to try shit out and learn.  That’s what it’s all about and not every organization can do that.  Some organizations need metrics or checklists or other ‘non-agile’ stuff and we certainly don’t need to tell them they are stupid for wanting that.  If that’s what their system can support, our message needs to change to adapt to their reality instead of beating them over the head with a bunch of hokey bullshit.

Demand for Agile is exceeding the capacity of those who really understand it so we’re left with people trying to make sure they are doing practice X right (as is evident by the billions of Linked In discussions I participate in).  It’s not their fault, all we can do as a community is adapt to serve our customers better.  That’s Agile.

Since I’m on ‘vacation’ I wasn’t particularly motivated to get it done, but obligation was calling so I caved even though I would have much rather done just about anything else.

It was hot, I was tired and not motivated and ended up doing a really crappy job.   I didn’t do the trimming or weeding and took shortcuts to get it done as quick as possible and as a result, I now have some yardwork-debt.   Oh, there’s a point…wait for it!I generally enjoy doing yard-work. There’s something about the accomplishment of getting it done and seeing a nicely manicured yard that feels pretty good.   Sometimes people walk by our place and I hear nice comments about how great the yard looks.  It may sound nuts, but it feels pretty good.

The shortcuts I took yesterday have made sure I have extra work to do next time.  The grass around the edges will be higher and will take longer to trim, there will be more weeds in the garden so it’ll take more time to pull them out.  Maybe that’s an extra 30 minutes or so next time around but the more serious effect is how bad I feel when I leave the house and see the half-assed job I did.

Who cares, it’s just the lawn right?

Wrong.

Obligation can yield the exact opposite results that it is designed to get.  I felt ‘obligated’ to do something I had to do, but didn’t want to do.  I had a choice.  Do it right or don’t do it.  I chose to do it wrong.  I chose to not communicate with my wife and tell her I knew I’d do a crappy job because I was hot and tired.  I chose to not defer the task until later in the day.

So how does this relate to Agile?  Well, I learned something.  I learned that next time I feel obligated to do this, I’ll take an extra 5 or 10 minutes before I start to clear my head and remember how crappy I felt after doing a half-assed job and then make my choice in a responsible way.

Responsibility and discipline are the magical ingredients for being successful with Agile.  All the process, metaphors and skills don’t matter if responsibility and discipline are missing from recipe.   When your team has improvements that come out of the retrospective, it takes responsibility and discipline to follow through with them.  They aren’t going to magically happen and your manager isn’t going to force you to do them.

Responsibility and discipline are the magical ingredients that make a difference between writing good code and crappy code.

Responsibility and disciplines are the magical ingredients that make a difference between building the right thing and building the thing we “have to” build.

What I personally find useful to be responsible and disciplined, is to simply take 30 seconds to re-boot my brain when faced with obligation.  I literally shut my eyes, take 3 deep breathes and say to myself:  ”what do you want to do?  You know ‘it has to get done’, take an extra couple of minutes and sort out your thoughts“.  While I’m doing the thing I chose to do (even when starting with feeling obligated to do it), I remind myself when feeling the need to take shortcuts: “Remember, you chose to do this.  Do it right.”

It’s quite possible I do that because I’m an introvert and I think mentally preparing yourself can go a long way towards doing the right thing, not the thing you feel obligated to do.

I decided recently to write a white-paper that describes the experience of the success of a pilot Agile team within a large enterprise organization.  What I hope to accomplish by writing this are:

• show that we are “breaking” some of the rules, but are experiencing success
• show the challenges large organizations have adopting Agile
• show the mistakes I made, the ramifications and how we forged ahead
• show that motivation is the most important factor in Agile adoption

How I’m going to structure the white-paper:

1. Introduction: who I am, context around why I took the approach I did and context around the organization.  The company name, projects and people names will be fictitious but the tactics, results and experiences will be real.
2. Iteration by iteration:  Starting at iteration zero and moving through our 6 iterations for 1 release I’ll show what our iterations looked like, what activities we did, how we co-ordinated with other groups, team frustrations and successes.
3. Summary of what we learned: How the team felt moving from old status quo to new status quo and why they would never go back to “the old way”.  This will also include what the team is planning to do for the next release in an attempt to show that despite the success, they recognize they are “not done” implementing Agile and want to get better.
4. Reflection: What I learned, what I would differently next time.
5. When will it be done?  End of December
6. How many pages? 10 pages tops, I would like to keep it concise

This is my first white-paper, I’m excited and nervous all at the same time, but this is taking me out of my comfort zone and it is quite challenging.  I welcome your input and feedback regarding what you would hope to get from reading this white-paper when it’s finished.

After the usual checking the Agile support box and responding to email I start working on some Agile flash cards we want to start distributing.  These are 3 x 5 index cards on various Agile topics that folks can use as a pocket reference guide.  This will help people at least get some of the lingo right so it’s not so confusing.  Right now any opportunity to see stuff is called a demo and when the product owner is preparing stories they often call it a planning session and are getting confused between this session and iteration planning.

10am – Stand-up time.   Since we’re only a couple of days into this iteration some un-expected tasks come up that the team didn’t think about during iteration planning.   I remind them to stick to the 3 questions and we’ll talk about those after.    There is still dysfunction in the stand-up but they are getting value out of it and I don’t think forcing them to the 3 questions and only those 3 questions is what is best for the team.  Yes it should be a guide, but the value of the stand-up is defined by the value the team gets out of it.

After the stand-up I remind them to update their tasks in our tool, as recommended by one of the programmers.    Then I ask them if they are pairing, they should add a duplicate task in the tool so each person can get credit for the work.  If it was up to me I wouldn’t bother but governance is governance and that’s far too big of a battle I’m not willing to fight right now.  Besides, it’s quick and easy and if it makes some managers happy, I don’t really care either way.

I close out the morning with preparing 3 sets of front-and-back flash cards and send them over to my mentor to review.

1pm – After lunch we have an emergency meeting with the QA manager about passing off our work to the regression/release/deploy process.   I make the mistake of being a bit smug with the fact we’ve automated our tests and we’re happy to sit with the QA team to show them what we did but in retrospect I realize I should have listened more to uncover why we need to go through this process.  I should have spent more time understanding what they need instead of being so nonchalant.

I guess I’m a bit irked that although this is a self-organized, fully cross-functional team, the business still wants governance and checks and balances.  At the end of the day, figuratively speaking, we’re only losing half an iteration for these activities and the product owner is satisfied so mission accomplished.

2pm – I do some research on the Estimating and Planning class we plan to deliver next month and it’s really tough to come up with material and not completely rip-off just about everything Mike Cohn has already done.  I am able to apply some ideas more relevant to our environment and make the material focus more on planning instead of the plan.

Upper management also wants some notes on the pros and cons of a short-term vs long-term transition plan so I jot some down and send them off to my mentor to get some feedback.  She’s handling this initiative because, well to be frank, she’s smarter than I am and has more experience.  I do enjoy participating in these activities but with the sheer size of the organization there is no shortage of work.

4:30pm – after reading a pile of blogs and a couple of videos I head out for the week satisfied with the result.

I hope you enjoyed reading this series of posts.  They accurately describe what I do day-in and day-out and everyday is almost like working with different clients as I get to participate in various teams and talk to many people throughout the company.   Hopefully you did notice some of the dysfunction with some of the interactions I described as well as what I did to handle them.  That was sorta the whole point of the series!  As usual, don’t hesitate to let me know your thoughts, the 2 comments I’ve received over the last couple of months are getting lonely!

I have a chat with the project manager who is handling the budgeting for our team and ask about the hardware we were supposed to get for the team 3 months ago, he lets me know it’s still on order and should be here soon.  There are some blocks a coach or Scrum Master just can’t remove and with an enterprise company and big, heavy-weight process, it is what it is, so we’ve been making do with what we have and pillaging spare machines for parts.

8:45am - Armed with a projector, sticky notes, markers and purpose, I head over to the training room and setup.    People start stumbling in and my observation about culture here over the last few months is that people seem to double-book themselves quite a bit or simple expect meetings to start late so I expect to start later than I thought.

9:15am - After sending out a reminder and getting a couple of last minute cancellations and a couple of no-shows, the class is down to 16 people and I get started.  I remind everyone that  I would appreciate it if they turn their Blackberries off and ignore them.  I offer to do the same knowing full well, based on history, some folks will ignore the rule.

Today’s session has a wide-range of personalities such as folks from product management, audit, release management and various analysts.   I find this really helps everyone understand the impacts of transforming to Agile for other co-workers in different areas of this department.

I won’t go into deep details about the class but essentially the first half is conceptual in nature.  We talk about the Manifesto, what it means and that Agile is not a quick fix solution and there is no checklist or easy answers.  I remind them that it would be simply crazy for me to convey that a 4-hour session is going to arm them with all the tools of the trade and that myself and my mentor are here to help when they want help.  Some are confused by that message and often I’m asked what the plan is to roll Agile out across the company and if we can just give them the answer.

They are a bit surprised to hear when I say that I don’t know the answer but I do have a whole bunch of knowledge and tools that will help us discover what works for us. We understand the way we are working isn’t working very well but it’s up to all of us to find the best solution.  I can certainly help guide that but my mandate isn’t to come in and order them to follow what I say.

The second half goes into more tactics where I talk about Scrum and Extreme Programming to help them understand the definitions and underlying principles.   I remind them again that if they like what they see, approach me afterwards if they want to learn how to apply them in their situation.

1pm – Class finishes up, I stick around for more questions and a couple of people invite me to some meetings for their group to further talk about how they can employ these techniques.  Some of the folks who were involved in early “agile” projects are relieved to hear what they thought was Agile really wasn’t.  There is danger is mistaking that just because you work in 2 week Sprints and have a backlog you are Agile.

I get some feedback from my mentor that I seemed nervous and I suppose on an unconscious level I probably was.  I have a great deal of admiration and respect for her so I wanted to prove myself.  She also tells me about a couple of things she would explain differently and tells me what those were and what she would change.  Luckily I also have my utility belt on so I jot down some notes.

3pm - After scarfing down a slice of pizza I rush over to our mid-town office for a meeting with a team in supply chain management.  They enjoyed the Agile introduction session last week and wanted me to come in and see if I could help them apply the practices to an upcoming project.

I listen to them explain what they are trying to accomplish and talk about a couple of approaches.  The key message I try to deliver is to collaborate.  Involve the whole team including the operators fielding the support tickets, the analysts, stakeholders and everyone involved in the project.  The wisdom of crowds is a powerful ally and I suggest they start off with a retrospective to start the dialogue.    After that, I point out that a brainstorming session would be a great way to figure out an action plan so they can at least figure out the direction they feel they need to go.

4:30pm – The meeting finishes up and I head home.

Sometime later that night - I check the Agile support mail box, respond to some emails and prepare an blog post on Retrospectives.