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!

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!

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!

I reported my impressions and notes of the meeting on the group website.  Head over there to see what I learned about agile developer excellence and Scrum developer certification possibilities.

Are your task's edges ragged?

The lawn was out of hand.  I skipped mowing one week for some reason and now it was far too long.  I attacked with the mower and with a desire to get the chore over as quick as possible.

Now with the grass cut low, I began to coil the mower’s extension cord and noticed the lawn’s edges.  They were ragged and unkempt.  I had failed to bring the edger from the back yard storage and was reluctant to take the additional 10 minutes or so to retrieve the edger and complete the task.  Besides, I had mowed the lawn, right?

“The lawn looks fine to passers-by,” I rationalized.  “Only people looking closely or actually visiting the house will notice the ragged edges of green.”

Declaration of Done Too Soon

Many times in design we are anxious to be done with a task or story.  It’ll look better on the burndown chart or on the task board if we call it done right then and fix up the “ragged edges” later.  We rationalize:

“It’s done and tested, I’ll check it into the repository and build system tomorrow.” Or “We should make sure the interface is the same as the previous version but nothing should have changed, so, let’s go to PCB.”

In agile practices, it is acceptable to define done as “just enough” to satisfy a story.  This is good since it prevents waste creating lots of details that have a high probability of changing.  But changing the definition of done to match incomplete or buggy results is a great way to build up technical debt.  The velocity of progress in subsequent sprints will suffer as the team has to put the final touches on what should have been done before.

Power of Transparency and Completeness

Keep your definition of done tidy!

Scrum and agile practices draw power from transparency of both process and reality.  This power has many benefits like:

• The customer knows what they are getting and when.
• The enterprise trusts the team to produce their commitment.
• The team enjoys space and time in the sprint to do their work.
• The end product actually works and has minimum bugs.

Harness this power!  Be honest with the team and your customer and make sure that something declared done really is done.  And make sure you always do the edges!

My Certified Scrum Trainer, Micheal Vizdos (@mvizdos, http://implementingscrum.com), taught in my certification workshop that Scrum Masters spend lots of time starting difficult conversations.  He was so very correct.  By this time I had already started many difficult conversations with leaders and managers about agile and Scrum.  I had faced the CTO and come away with support.  But I worried about talking to this collegue.  I had fear of this engineer because:

• He was very skilled in the craft, with knowledge and the ability to create great software.
• He had a strong personality, able to decide what he wanted and work for it.
• He pulled no punches, stating his opinion with conviction.
• I admired his abilities and work ethic.
• I didn’t know him, personally, very well.

In other words, to face him I had to know what I was talking about and put my beliefs in the line of fire.

One day, with my training ringing in my ears, I asked him why he objected so strongly.  A difficult and rewarding conversation followed.  It was the beginning of understanding, of many more conversations and of working better together. (I’ll write about the content of that conversation another time.)

Shortly after that first conversation, I started reading “Fearless Change: Patterns for Introducing New Ideas.”  The book describes a pattern or method for helping your change efforts by enrolling a “Champion Skeptic” to help.  In a private moment with the objecting engineer I informed him that he was my “Champion Skeptic.”

Surprise: He was skeptical.

Months have passed and our discussions were more helpful than he knows.  He suggested task card improvements, important impediment removal and improved build processes, among other things.  He also blocked some progress in different ways, but that was the skeptic part.  Most important to me, he helped me improve myself.  I was able to present ideas better and improve my arguments for Scrum and agile practices.  He helped me understand deeper his points, and my own.  And we became more friends than just coworkers.

This week he announced that he is leaving the company for other adventures.  The technical loss of his skills to the team and company will be felt for a while.  The loss to me as Scrum and agile evangelist is also significant.  I now need to find another “Champion Skeptic” against which I can hone my skills as change agent.  I’ll need to find someone to talk straight and cut me down to size when my thoughts and ideas fall short.  Oh, I can find people who don’t “believe” in agile, but one who also provides open, truthful conversation is not easy to find.

Who helps you break the echo chamber once in a while, to see what others see?  Who makes you a better agile advocate and practitioner?