Context

If Agile is about people, it’s surely about communication.  Let’s start by looking at a few things we know about communication:

• Some say human communication is only 7% words while the remaining 93% is verbal and visual (http://en.wikipedia.org/wiki/Albert_Mehrabian).  While some might argue the exact ratio, I agree that face-to-face communication is by far the best way to share information and create.
• The ability to grasp abstract subjects and invent is severely damaged by context switches and distractions.
• Understanding the history and context of a subject increases the ability to be productive in that subject.
• Any change in the membership of a group (team) will disrupt the relationships and communication paths of the group.  It will take time to reestablish the previous levels of efficiency.
• Any person highly experienced in a general skill area will need to learn the basics of any specific situation before they can be fully productive in that specific situation.

Almost anyone would find the above statements as reasonable, even intuitive.  And yet, point by point, common real life situations continue every day:

• Work environments are designed such that the use of anything more than email, instant messaging and documents very difficult, if not impossible.  IT policies and work requirements force dependency on only words and eliminate the rich audio and visual channels we naturally know.
• Day after day we are required to change projects, product focus and attention.  Some engineers I know have as many as 12 or more projects to keep in the air.  Details are lost in the context switches.
• Developers and other workers are thrown into projects with no information about the purpose of the work, the roles of the people involved or the value of the product.  Instead of listening and building the confusion of purpose reigns.
• Individuals are “resources” to be plugged in and out of “teams” at will and whim.  Long term relationships with shared experiences building high communication connections never happen.
• Questions about basic information are met with chastisements from peers and managers.  For some reason people are expected to know already without any training or orientation.  People learn to not ask questions.

Innovation Sabotage

Pushing people into situations of poor communication, severing communication paths and obfuscating information will not produce real innovation.  Working harder and longer will not make up for the damage.

I’ve attended meetings where top executives tout technology and projects that will propel the company to new heights of profitability.  They point out the places in the plan where differentiating innovation will be created.  Difficult problems will be solved to create the products and success that will come.

And, the company does not allow the use of internet video conferencing.  And defines projects based on “resource” skills without regard to geographic location.  And has key projects running with no defined structure or governance models.  And considers “fire fighting” just the way the industry works.  And requires heavy sign off processes by people who don’t know what they are approving.

Many times the disconnect is both huge and invisible to the executives and even the people working under fog and confusion.

Agile Means Transparency

To be Agile means communication about everything.  Finding ways to easily share everything such that when data is needed, it is readily discovered.

• Don’t eliminate up to 93% of human communication capability, enhance it.  Put teams in their own rooms, not cubes or offices.  Design product development structures to support co-location instead of distribution of people.
• Give teams goals that don’t change all the time and members that are dedicated to the team, not split multiple ways.
• Explicitly define and publish team structures.  Allow new people to be trained on products and processes before they are required to be fully productive.  Organize the information in radiators that passively keep people in the know. Give people time to learn them.
• Projects and products come and go.  Teams should not.  Allow deep relationships to form and cultivate over time from project to project.  Soon you’ll have teams that can do anything you throw at them.
• Basic questions should be welcomed and the answers immediately available.

People Problem, People Solution

Every problem is a people problem.  Every single one.  Ask people to solve the problems.  If you are a manager, business owner, vice president, you are the creator of the work environment.  Don’t forget the people and people attributes.  The power of people allowed to communicate fully is far beyond any technology or process.  ”Individuals and interactions over processes and tools” is not just some feel-good mantra.  It is what we need to solve our problems and innovate!

My Mentors

• Don Dayley, my father – Taught me all the foundational things in life, including how to mow the lawn when I did not want to, sometimes through uncomfortable methods.  He also gave me an unsurpased example of attention to craftsmanship.  Everything he builds or repairs is better than new when he is done.
• Mrs. Fedler, 4th grade teacher – I found most of my first three years of public school boring.  Mrs. Fedler found ways to show me that learning itself was fascinating.  And she showed me that exploring the boundaries beyond expectations was praise worthy.
• Mr. Douglas, 11th grade chemistry – THE hardest teacher I ever had, including college.  The scientific method, analysis, reporting, supporting conclusions based on facts and failing with good humor are among the things he taught me.  Ask me why he sometimes called me “Beaker.”
• Pedro Brassinini – Taught me to love strangers more than I ever dreamed possible and to feel compassion deeper than I had known.  And how self-sacrifice brings inner rewards.
• Bill Sheppard – My first engineering boss was hard and understanding with me, a green engineering student.  He showed me that trust is part of doing my work well.
• Kevin Kilzer – A brilliant engineer of software and hardware.  He harnesses passion for the work like no other coworker in my experience.  Creativity fueled by inner fire is awesome.
• Mike Vizdos – A guide over the years of my journey into the Agile and Scrum world.  Quiet thought is a powerful tool, which he knows and shows how to use in all his work.
• The Ignite Phoenix Team have shown me Agile collaboration skills and community building prowess that I hope rubs off on me.  (Don’t tell them they are Agile, they’d get too self-conscious.)

I could go on with more mentors, some who don’t even know the little, important things they have taught me.  You should take some time to make your own list, even just mentally.  You have had some great mentors too, or you would not be where you are.

Gangplank Mentor

Before I knew January was Mentor Month, I was invited to be a member of the mentor team at Gangplank.  I’m one of the mentors on business operations.  Once a month, more often when I can, I’ll have office hours at Gangplank.  You can book a 45 minute session with me to ask questions about Agile and Agile frameworks like Scrum and Kanban.

My first mentor day is in the afternoon of Tuesday, January 25th.  No fee, just set your appointment with the Gangplank Director of Operations and let’s talk about taking your operations to the next level.

I can’t necessarily give back to all the mentors in my life.  But I can give to someone, who can build something great and give to someone else!

Gangplank is a place and movement that redirects us to see the people. Where we see the value of tapping the full human, not just functional skills for a corporate machine. My work to bring agile concepts into corporate environments is a similar effort. Gangplank strengthens me in my quests.

Please step over and give the post a read.  If you don’t know about Gangplank, I hope this will provide your first taste of that community.  Lot’s of people there live and breathe the principles of Agile!

• First, I thank Rally for putting on this event here for us. They served a nice breakfast in a nice environment. The cost of the venue combined with the number of staff present was a significant investment in the Phoenix Agile community. Sure, they got exposure and marketing information. They also succeeded in producing and event that was neither pitchy nor preachy.
• A lot of people were there. I estimate at least 60 and there were still name badges left on the table. It was a strong showing of Agile interest here in the area.
• I thank the panelists from three local companies; Pearson, Universal Technical Institute, Infusionsoft.  They shared their stories and answered questions. This sort of sharing is important for all of us.
• Many of the questions from people showed a real desire to do things “right” and smart. The struggles are all different but we are not alone in performing them.
• I noted some of the company names on the name badges. The diversity was surprising to me. There were people from retail, utilities, government and heavy industry. Wow!
• I enjoyed meeting different people and sharing some points of interest or question. The community here in Phoenix has some great people!
• Lastly, I thank Chris Conrey from Integrum Technologies for car pooling with me. It was a quick trip and made the better with conversation. And he paid for parking!

I hope to see many of the same people at next Wednesday’s Phoenix Scrum User Group meeting.  Should be a great event!

That is a hard question to answer.  Not for a lack of information, but because there is so much out there.  A great problem!

To answer the question I just sat down and started typing a flow of information.  Below is the email I sent to the him, largely unchanged.  Eventually I should turn this into a polished document.  I hope you find it valuable and get a starting point that works for you!

Learning

First, I have a few Agile learning philosophy tips.  I’m sure you have your own learning style and I don’t want to pre-empt that, just give you a frame of mind.

Focus on “academic” (pure) knowledge before you dive into “useful” (applied) knowledge.  But, remember that full understanding doesn’t come without application.

There are many things about Agile that are so different in thinking to traditional project and people management that we may want to reject some parts and pieces right off the bat.  Suppress this reaction by seeking to first academically understand the concepts and practices. Like you are just taking a class in college that is a general education requirement with no thought of actually applying it after the final exam.  But you do need to get an “A” on the final, so learn the topic.

Work through the application stages of knowledge.  A concept pulled into Agile from marshal arts is “Shu-Ha-Ri”

• Shu - You learn and do the basics, sometimes without knowing why, because the masters say so.
• Ha - You begin to mix your own experience into the basics, learning where your knowledge can enhance the new knowledge.
• Ri - You are a master and the basics are just part of what you do, are now part of your experience.

Individuals, teams and enterprises go through these stages all the time.  The hardest is to accept the Shu stage because we have to unlearn other habits and trust the new knowledge.

It’s about people

As I stated in my presentation, Agile is about people.  Yes, eXtreme Programming (XP) is a set of Agile practices that tell developers to pair program and other specific things.  Yes, Scrum is a definition of certain meetings, documents etc. that help a team work in a more Agile fashion.  But these and other Agile frameworks are designed the way they are because it is the best way for people to communicate and work together.  Don’t let the practices become more important than the people.

Agile Manifesto

The definition of “Agile” may be ambiguous to you.  It also takes some abuse in companies who claim to be Agile but really only have some of the outward practices without following the true spirit of the movement.  To remove this confusion, go to the Agile Manifesto website, read, study and learn the statements and the principles.  If you are working to follow these ideals, you are becoming Agile.

Frameworks

The Agile Manifesto was created by smart people who had already developed one development framework or another, realized they had some common foundation and got together to define that foundation.  So, one of the best was to start being Agile is by learning and using a framework. The more popular frameworks (sometimes called methodologies) are, in my view:

• Scrum – The one with the most traction and widest use.  It is a project management level framework that focuses on the development team.  It is simple to understand the basics and get started but that makes it simple to do the motions without being Agile.  I started with this framework.
• eXtreme Programming – XP is also well known but not widely implemented.  It has some of the same elements of Scrum but emphasizes engineering practices where Scrum does not.  Pair programming is the most well known element of XP and probably the reason many reject it. XP and Scrum work very well together.
• Kanban – This one is currently gaining in popularity and originated out of lean manufacturing ideas.  It concentrates on work flow, making the flow very visible, thereby exposing bottle necks and waste that should be corrected.

I found Scrum the easiest to personally pick up and to evangelize into the enterprise.  Practicing it for three years now, I have much still to learn and am seeking wider Agile knowledge.

Online Resources

The internet is FULL of great resources about Agile.  Videos, presentations, blogs and email lists abound.  And it is just as good as what you find in books.  So don’t be afraid to go searching for things.  You will find treasures!  Let me give you some starting points.

• http://mountaingoatsoftware.com – This is Mike Cohn’s website.  He has written excellent books on Agile like “Agile Estimating and Planning” The site is full of good ideas and, I think, the slides of every presentation he has ever given.  A gold mine for learning.
• http://implementingscrum.com – This is Micheal Vizdos’s website, a Certified Scrum Trainer.  He uses cartoons to poke fun and knowledge about Scrum.  He was my ScrumMaster trainer and still helps me today. His training style is thoughtful and active.  If you want to take a course, he’d be a good trainer to pick.
• http://groups.yahoo.com/group/scrumdevelopment/ – The email group for discussions of all things Scrum.  All the Agile luminaries, it seems, show up here and answer questions.  Troll the archive for great practical advise.  If I could never buy another book about Scrum, I’m not worried because this group has all the authors brain’s wired!
• http://video.google.com/videoplay?docid=-7230144396191025011 – This is a video of Ken Schweber speaking a Google about Scrum.  This was the first video that hooked me into learning about Agile.  It’s worth the time even though Ken is a bit dry.
• If video is a good learning mode for you, check here: http://agileroots2009.confreaks.com/ for videos of all the session of the Agile Roots 2009 conference.  Great stuff there!
• http://phxsug.org – This is the Phoenix Scrum Users Group website that I mentioned at the end of my presentation.  We have monthly meetings on the 3rd Thrusday of the month.  We focus on Scrum but other frameworks come up from time to time.

Books

• Anything by Mike Cohn.
• “Agile Retrospectives: Making Good Teams Great” is awesome for doing this key element of team building practices.
• If you are introducing these practices into a workplace, you need to be a great change agent.  The book “Fearless Change” is indispensable knowledge for such an effort.

There are many more great books out there.

Try it!

The best way to learn is by doing.  Apply some of the principles and framework pieces as you can.  Try a retrospective or make a task board.  Use it, inspect how you did, adapt and improve.  That’s how it works.

Training

Education is compressed experience and a good class can jump start your improvement efforts.  If you don’t feel up to pushing change in you organization, hiring an Agile coach is a good investment.

Ask Questions

Find a community, site or friend.  Ask questions of them and yourself.  Ask here if you like since I like to answer!

Slides

This presentation is the first I have posted to SlideShare, an interesting experiment of itself.  Please have a look:

Questions

At the end of the presentation and after the presentation time, two smart people had some interesting questions.

Question 1 – When the client is expecting to know when it will be done and how much it will cost, how does a provider using Agile respond?

Dallin Harris of Skyhook Internet Marketing brought up this difficult topic.  Agile practitioners everywhere work at the difficult balancing act of providing the information the customer wants and educating them to understand the benefits of Agile iterations or sprints.

We discussed the finer points of productivity, such as always working on the currently most important feature, delivering finished parts as they are done at each sprint end and the ability to stop before every possible feature is created if the current version is enough.  We also found a direction point to the Product Backlog and how it feeds a release plan for the client to interact through.  I pointed him toward Mike Cohn’s excellent material around estimating and planning.

Question 2 – How do we get team cohesion if the Program Managers are assigning tasks?

David asked this question about a common problem in an organization transitioning from a more traditional structure.

The short answer: In such an environment, cohesion on the team is not possible.  Or, at least, it’s very hard!  When people in authority direct individuals on the team, the team cannot self-organize.  And, it’s not Agile.

We discussed how David needs to help the Program Managers direct desired work per team instead of per individual.  This has many benefits to the team, the Program Managers and the company.

• The team has a chance to become self-organizing.
• The team members are not wondering what they will be doing next, as they have a full sprint to work the plan.
• The Program Managers will see completed work sooner.
• The Program Managers will drive the company to ensure it is working on the most valuable features and projects first, providing focus.

These are the things David and I discussed.  I wish him well in his quest to increase agility where he works.

Twitterings

After the event I finally had a chance to look at my phone.  The mentions on Twitter had exploded!  That was very gratifying and I thank you all for the attention.  In particular, Bold Avenue was in the audience and live tweeting many of my significant points.  (Thank you, Stephanie!)

A great experience.  I learned a great deal and hope the community enjoyed my small contribution.

The best way to make sure a poster has value for your company or team is to start out with good information.  Platitudes don’t cut it.  Real value from the information is the best measure of good content.  Let me tell you about the most powerful poster we have in our office.

Some time ago I encountered the presentation “I don’t like Mondays” presented at Agile 2007 by Jean Tabaka.  Her presentation is an excellent summary of great things that energize meetings of all kinds, and Agile meetings in particular.  (After you read this post, go watch the video.  It is well worth your time!)

In the presentation, Jean provided the content for our poster as a “Focus On / Focus Off” list about communication.  A picture of the poster is to the right, hanging in our main meeting room.  The simplicity of the content belies it’s power:

Focus On / Focus Off

Inquiry rather than Advocacy

Dialogue rather than Debate

Conversation rather than Argument

Understanding rather than Defending

Why

We found that hard decisions in our meetings led to some conflict.  Conflict is to be expected, even desired, in creative work.  Passionate and creative people will have conflicts if they are effectively engaged.  The trick is working through the conflicts such that the customer and the team are happy with the results and each other.  An Agile team needs to learn tools of compromise, knowledge transfer and empathy to get through the conflicts that will come.

One particularly contentious Sprint Planning meeting bothered me as we proceeded into the Sprint.    We had simply postponed some of the difficult decisions because the logjam of opinion was impenetrable.  (Everyone was civil but feelings were strong.)  As we approached the end of the Sprint, I worried about the Retrospective and the planning to take place after that.  How could we quell the conflict enough to make decisions without damaging the team?

One evening, during the last few days of the Sprint, I found the video of Jean’s presentation.  I had to try this “Focus On / Focus Off” discussion!  I wrote the title and described how our internal focus changes the context of our communication.  I then wrote each “rather than” pair one at a time and asked a team member what that pair meant to him.  I then asked another team member how one would act or speak if focused on the left word and then on the right word.  I did this with each pair of words, discussion their meaning and effects.  I then asked that we each do our best to focus on the words to the left as we work through the retrospective and planning.  I then taped the easel page to the wall as a reminder.

The feel in the room softened, opened as we had this discussion.  Yes, that sounds all “warm and fuzzy” but it is true! The Retrospective was excellent and the Sprint Planning meeting that shortly followed was very fruitful.

Power

Can a poster have such power?  If you have a Scrum Team willing to work for the better of the project, for the customer, it can.  We each need occasional reminders about what open communication really means.  A reminder that our thoughts are valid and need not block all other ideas to retain validity.

Today, more than a year later, the hand written poster hangs on the wall right where it was first taped up.  It still helps us to disagree, learn and grow.  And work with each other the next day!

The feel in the room was largely up-beat but had some unspoken tension. I shifted gears quickly to start different than planned. I asked that we go around the room and each member give two statments:

• Give one word that summarizes this sprint for you.
• Describe your passion about this sprint, team, project or company.

The one-word summaries were balanced between words like “progress” or “satisfaction” and “frustrated” or “bottleneck.” (Ah, the tension comes out.) This was reasonable given that not all the stories were completed this sprint.

The passion statements were great! They ranged from love of creating new technology to the joy of shipping actual product.  We all learned interesting things about each other.

And the tension was over. Just like that, it was time to dig deeper into the sprint with clear heads and a forward view established as a great foundation for the meeting.

Personal Trill

My personal moment of happiness came during the expressions of passion. Two engineers spoke of the team’s effectiveness in powerful terms. To paraphrase:

The is the most productive team I have ever worked with in my entire career.

I didn’t think I would ever enjoy working on a team larger than 3 or 4 people, but this experience shows otherwise.

What a great team to work with!

A Holistic Enterprise View

The whole enterprise can be thought of as a circle.  This circle is divided into three areas of focus.  These three areas are almost never equal and will vary based on size, age and needs of the enterprise.  Yet all three are present, if sometimes neglected in turn.  The picture is like this:

Work

This is what the enterprise does, what it is paid for.  Work is the product and all the production performed to create the product, tangible or digital.  Work is the sum of the actions, the designing, writing, testing, coding, speaking, drawing, etc. that create what the customers buy.  This is the highest focus of the enterprise and rightfully so, for without this, the enterprise cannot sustain itself.

Information

This segment of the circle represents the data or artifacts either produced or needed to do the Work.  This is be source code, documentation of all types, emails, invoices, meetings, logs, procedures, accounts payable or receivable, etc.  All enterprises large or small have and produce this data which must flow efficiently for the enterprise to do well.

People

This third segment represents the people and their interactions as they do the Work.  This is management, hierarchy, social behavior, teamwork, conflict, collaboration, politics, disagreement, personality, etc.  In order to accomplish the Work, people must communicate and interact.  It is a huge, yet intangible, component of the enterprise.

Focus Areas

Each of these three areas, Work, Information and People, must function together.  Work is always there, it is the reason for existing.  When a company first starts it may be only one person or perhaps a few more.  In such a situation the Work dominates all thought and effort.  This is OK because a small group can usually move Information quickly and get along well as People.  As an enterprise grows, difficulties within the Information and People areas more significantly impact the Work.  From cultural habit, the enterprise will want to continue to focus on the Work but there must be people designated to prevent neglect in the other two areas.

• How long does it take for a developer to learn about a field problem in a product?  The answer to this question is one measure of how will the Information area is doing.
• Does a person on the low end of the hierarchy feel safe to tell his supervisor or even division manager about a problem?  This is a check on the People part of the enterprise.
• When the lab needs new equipment, how hard is it to get?  This can touch on both Information (purchasing procedures and documents, etc.) and People (asking the manger to change the budget).

Keeping these three areas balanced according to the current needs of the enterprise is the primary function of mangers.  They have the authority, position and mandate to ensure that the Work does not suffer because of neglect with the Information and the People.  A great enterprise, dare I say an Agile enterprise, makes sure the Information moves quickly to the right place at the right time and that the People are interacting in high performance!

A Holistic Team View

This discussion started with a view to the enterprise but let us conclude by boiling it down to the Agile team.  What do these three areas of focus look like when we use them to view a small working group?

• The Product Owner pushes Information flow about what the Work should be.  Features, progress, vision and direction are controlled by Information in and out of the team.
• The ScrumMaster focuses largely on the People part of the team.  He helps them resolve conflicts to create constructive outcomes.  He creates environments in and out of the team that allows for trust and truth to be visible.
• The Team of developers focus on the Work, the product and the components that make it.  With the Product Owner providing Information direction and the ScrumMaster maintaining a People friendly environment, the Work gets all the attention it needs for high quality and speedy production!

Note that each of the Agile team roles must keep the whole circle in mind and overlap, for all three areas are important.  But each role as the area on which they focus the most.

For me the point of this view is simply another way to look at enterprises and teams.  For me it brings more clarity to my roles as ScrumMaster and Agile Coach.  Us it as a tool help you think about where you are and where you can create more value for your enterprise and team!  Let me know what you think about it.  I’d love to learn more!

Certified Scrum Practitioner

The end of September my application for Certified Scrum Practitioner was approved!  How I could have been quiet about that I don’t know.  The process was interesting.  My first submission draft resulted in some requests for additional information.  The requests were spot on, pointing out weaknesses and missing information.  I was very glad for the review and extra work.

Approval took around two months.  I was disappointed and worried about this slow turn-around.  Of course, this was also the time of the recent tumult when Ken Schwaber and Jim Cundiff left the Scrum Alliance.  Maybe that had an effect on the processing time.

Gaining the level of CSP had been helpful with my work.  A few skeptics who actually know little of Scrum or Agile have expressed some additional interest after learning of the new level.  Some seem to take me a bit more seriously.  I see this as a positive benefit, but a minor one.  Continuing the learning is more important to me.

PhxSUG Topic Tables

October 21st the Phoenix Scrum User’s Group had our monthly meeting.  This time we concentrated on drawing for ideas from each other.  We declared the event “Topic Tables” to have multiple discussions at once around various topics.

After we wrote suggested topics, we voted on them as a group.  The four highest vote winners were distributed teams, integration of Scrum and traditional project management, calculation and use of velocity measurement and measuring performance of team members.  I found it to be a fun and interesting way to do the meeting.  It allowed for both learning and getting to know new people.

Ignite Phoenix 5

I posted earlier about my involvement with the crew of volunteers working on Ignite Phoenix events.  Last week Ignite Phoenix 5 went off so smoothly, I still can’t believe the lack of drama for us the organizers.  I love the Phoenix area and the great people on the team and that attend our awesome events!

Local ScrumMaster Discussions

I have been enjoying more interaction with local ScrumMasters and Agile practitioners.  In particular, I enjoyed a recent discussion with Chris Young, ScrumMaster at Integrum Technologies.  He has some great ideas and questions around working with small teams and handling the Product Backlog.  The contrast to the large teams I am currently working with was very interesting.  I hope to do some story workshop study with him very soon.

Developer Ignite 2

While I have worked on organizing Ignite events, I have never presented at one.  A few weeks ago I submitted a topic for Developer Ignite 2.  Intel has a significant presence in the Phoenix area.  They have taken up to sponsoring an Ignite event centered around software development topics.  My submitted topic is “The True Measure of Agile,” which was accepted for presentation!  The event will take place tomorrow, on the evening of November 11th.  I have been practicing my presentation as much as possible.  20 slides in 5 minutes without stopping is not easy to work in!  Certainly forces focus on the core message.  We’ll see how I do tomorrow.

My desire is to reveal the need to work toward the values expressed in the Agile Manifesto.  That whatever framework or practices you use, it’s not Agile unless these values are supported.  I’ll find out if I can do that in only 5 minutes!