Scrum – Ease The Hard Parts

I have participated in this volunteer event in the past and this Saturday is no exception.  I will lead a session at 10:15 AM where we will review the Scrum framework and discuss the places where the framework can be hard to implement.  We will share experiences and techniques for getting through these places for even better performance.

Agile Content Abounds!

Before I list the many sessions about Agile and Scrum, let me remind you of an important point.  Desert Code Camp is free, as in no-cost.  A free opportunity to learn, ask questions and discover gems from practitioners sharing their experience.  Find a session or two or more to take advantage of this community gift!

Here are the sessions related to Agile and Scrum, gleaned from the schedule for you!

• Thinking Agile by Martin Nagel
• Scrum . . And by Ken Ward
• Introduction to Domain Driven Design by Craig Berntson
• Behavior Driven Development From The Trenches by Lee Brandt
• Everyday Extreme Programming (XP) by Clayton Lengel-Zigich
• How To Manage Self-Organizing Teams by Jade Meskill
• User Stories and Release Planning – Difficulties and Nuggets by Perry Reinert

Classes for Kids

There are a number of sessions designed specifically for children to get hands-on experience programming and creating.  Thanks to Gangplank Jr., you can bring your young offspring to learn programming with Scratch, build Lego robots and other things.  Check the schedule for these classes marked with minimum age appropriate notation.

It will be a great Saturday!  If you don’t attend my session, look around for me to say hello before the day is done.

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!

Gangplank Academy

Gangplank is a wonderful dream made real by Derek Neighbors, Jade Meskill and other community minded people.  It is community centered co-working at no cost, and therefore priceless.  Visit their site to learn more about their work.  Especially read the Gangplank Manifesto which, in my opinion, drives Agile values into the realm of community building.

One of the efforts of Gangplank is to provide education opportunities for the community.  They work to provide the infrastructure for people to share expertise and learn from one another.  Regular business and technical “brown bag” sessions happen every week.  Other conferences and events are scheduled regularly.  All of these events together are create The Gangplank Academy where learning on many subjects and for all ages takes place.  This workshop is designated as “AGL-101″ since it is part of the classes of Gangplank Academy.

AGL-101

I am hoping for a great mix of Agile and Scrum knowledge as well as a mix of work focus in this class.  Software projects have traditionally been the focus of Scrum application.  This is logical since it was created from that industry.  However, creators of software product aren’t the only ones who can benefit from Agile values and Scrum.  Management, marketing, operations and other facets of the business of production can be improved by application of high interaction and clear communication.  I encourage you to invite your peers and people “outside” of software and engineering work to spend this bit of time to learn with us.

RSVP

The event is available on Facebook.  If you would, please RSVP on the page.  This will help us plan for the proper room and tailor the class appropriately.  Comment on the event page too.  All the communication we can get helps us help you!

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.

This Wednesday, March 24th, I will be the featured speaker at the Brown Bag session. I’m very excited to give and get some education with the Phoenix creative and small business community! My presentation will be:

Business Benefits of Being Agile

Agile practices such as Scrum and Extreme Programming are touted as a way to improve software development teamwork and their results. There are benefits to the business in and out of the team that are not always obvious at first. I argue these benefits are large enough, any business should jump to apply Agile any way they can!

Please come participate in the discussion. I’m sure you will enjoy it!

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!

The True Measure of Agile

I’m passionate about Agile and the power it brings to the people who apply it as intended.  I’m also frustrated by strong evidence that many who speak the words of Agile development are only wrapping the same old practices in buzz.  This is very bad for Agile and developers everywhere.  So many times I’ve talked to engineers who “did Agile” or “did Scrum” and then proceed to describe a broken and painful experience of micro-management or loosely controlled chaos to failure.  Coaching someone back from such a false agile implementation is often harder than pulling them out of waterfall.

The goal of my presentation was to point people back to the Agile Manifesto, to consider that there are meanings and values behind those words.  Pick a framework, like Scrum or XP.  Combine with practices like TDD and continuous integration.  Do your “stand-up” meeting sitting down if you want.  But make sure you check against the Agile Manifesto to keep driving to what Agile really means.  That if those values are promoted by what you are doing, whatever it is, you are on the “true Agile” path.

My slides are available below for download and reuse.  Because the Ignite format allows only 15 seconds per non-stop slide, there are few words, if any, on most of them.  Perhaps you will find better words than mine to fill in!  Let me know what you think of the message you get from them.  The video will be posted soon at the event web page.  Then you can compare what you thought to what I said.

• Download presentation as an ODP. (Open Document Presentation format, as with OpenOffice.org Impress)
• Download presentation as a PDF.

What I Learned

All of the presentations were great! A few points that stood out for me were:

• Tomasz Stechly (@tstechly) introduced me to the concept and benefits of immutable code.  I’m now sorry to say it’s not a technique I have looked into very much.
• Derek Neighbors (@dneighbors) highlighted that we have too much information to slog through every day and that geo-location is one of the ways we can filter the flood to get at what is relevant where we are standing right now.
• Leo Godin (@leogodin217) re-enforced many of the things I read about getting to done and giving what the customer wants, a solution.
• Clayton Lengel-Zigich (@claytonlz) told 10 fables from Aesop and applied each of them to software development, including pair programming and TDD!

All of the presentations were great! I said that already and I’ll say it again, if anyone asks.  Such talent in the Phoenix area!

Thank You

I give thanks to everyone who sponsored, organized, promoted and spoke.  Especially I thank the audience for an awesome experience!

It’s Work

When I contemplate why I do all this extra work in my spare time, I sometimes conclude I must be cazy.  Extra meetings, lots of email and phone calls, sometimes dealing with difficult situations or people, giving up evenings, days and weekends for the priviledge of working in the hot sun or wrangling a meeting.  Whew!  Am I nuts?

What I get out of such work is valuable to me as a person.  The thrill of helping others, enjoyment of a back-stage pass to a special event, working with great people and learning about myself make all the extra work a small price to pay.

It’s Beneficial

Think about the last time you volunteered to do some work for a community group.  Might have been small, like ushering for one evening event or maybe large like months of planning for an all day festival.  Why did you do it?  How did the leaders of the group “rope you in” to giving up that much time in your life?  You might answer similarly to me.  Here are some other possible reasons:

• You want to help achieve a great goal.
• You enjoy recognition and feedback about your work.
• You seek an avenue for personal growth.
• You wish to give something back to the community.
• You want to bring about social change on a larger scale by working with others.
• Your family needs help and support.
• You are seeking friendship, support, bonding and a feeling of belonging.

When we volunteer based on any one or more of these reasons we are motivated, energetic and worth our weight in gold to the communities we serve.

Agile Connection

You might ask what volunteering has to do with agile practices.  The more I work with agile, the more connections I see.  Some examples:

• Introducing Agile Practices – When introducing agile practices to a traditional environment grass-roots and top down support must both be present.  The agile evangelist must gain the support of many at both the developer and management levels in the organization.  In other words, people at multiple levels of the organization must volunteer to participate.
• Planning – Frameworks like Planning Poker help draw all participants into the planning process.  The Product Backlog, estimating, etc. rely on input from stakeholders and developers alike.  They are expected to volunteer this information into the process.
• Daily Meeting – A fully performing team does not wait for the Scrum Master or other person to direct the meeting.  Each participant volunteers to report what is done, what will be done and any impediments.
• Retrospective – Ever been in a retrospective where the participants don’t offer any input or feedback?  Doesn’t work unless people volunteer information and honest evaluation.
• Self Organizing – Teams used to being told what to do have a hard time volunteering for self control.  And that is what it takes to self organize.

Command and control is the antithesis of volunteering.  A leader that uses command and control will never get the high energy, power and creativity that a dedicated team of volunteers can produce.

Getting Agile Volunteers

I have found that participating as a volunteer worker or leader in community projects is a valuable experience.  I watch myself and others to learn why we volunteer.  I watch the leaders to learn how they nurture the volunteers and the organization.  Look at the list of reasons one might volunteer for a community organization.  It’s probable the developers and managers in your work place are looking for many of those same things!  Volunteering experiences can be reapplied to transform reluctant agile participants into powerful volunteers!

Do you volunteer or lead community volunteer organizations?  What have you learned about creating “volunteers” for your business and team’s success?

This morning James posed a question about sharing lessons learned between teams:

Any quick suggestions on how to facilitate a retrospective over a team attending training to decide how to teach what they learned?  (http://twitter.com/jamescarr/status/1706359397)

Scrum and other agile methods promote the practice of regular retrospectives or team reviews at the end of each interation.  The team spends time specifically evaluating things that went right and wrong during the last development sprint.  This way the team learns to get better and better over time.

If your company has several or many teams, wouldn’t it be good to spread the lessons each team learns with all of the other teams?  And, if you have a new team with developers new to agile practices, wouldn’t it be good to prevent them from “re-inventing the wheel” on their path to being a great team?  Certainly these are great goals.  To the question posed by James, what is good way to pass on this information?

As I attempted to respond, a thought struck me about new agile teams and how they can learn to be great agile teams.

• During or just after a retrospective, write down the team’s lessons as an agile story on a story card, following the template wording using roles.

As a <role> I/we should <learned behavior> so that I/we can <benefit of learned behavior>.

• Set aside a wall, literal or virtual, on which these story cards are placed.  The wall must be visible to all teams.

These lesson stories become a “Product Backlog” for producing the ideal agile team!  Heck, a department director could be the “Product Owner” and prioritize the lesson stories for the teams to ensure they are applying the lessons!  I get excited just thinking about the learning culture this could create!

I need to figure out how to do this with our teams!

I have not tried this yet, nor have I heard of the idea anywhere else.  I’m sure there are many ways to share lessons learned between teams.  Comment below on your thoughts of this “Team as a Product” idea or other ways that help share lessons between teams.

Those familiar with Scrum and XP and other agile practices know about the daily team meeting.  Sometimes called a “daily stand-up,” this is a meeting held every day at the same location and time.  In this 15 minute meeting the team usually stands in front of the team board to discuss three questions, and three questions only:

A Simple Task Board

• What did you get done since the last meeting?
• What will you do before the next meeting?
• Do you have any impediments to your work?

The team board has story and task cards that are moved across to document the progress of each task.  Each team member owns the task he is working and signifies that ownership by moving his task cards in turn as he answers the questions.

So what is the elephant in the room?  In this team’s case, it is the table.  Yep, a simple and useful object that decreases the effectiveness of the daily team meeting.

This team does not have a dedicated team room.  This less than ideal situation is handled by using a task board on wheels that lives in the hall where the team members work for visibility throughout the day.  The board is wheeled into a conference room for the daily team meeting.  The conference room has a table in the middle.  A large one that is difficult to move.

The team board is placed on one side of the room and, due to the limited space directly in front of the board, the team groups on the other side of the room.  With the table in the middle, between the team and the team board.  Suddenly, it is too cumbersome for each team member to come around the table and move their own task cards.  The ScrumMaster stands at the board to move the cards for the team.

List the damage:

• Team disconnected from the task board
• Members disconnected from ownership of their tasks
• The meeting feels and operates like reporting to the ScrumMaster instead of reporting to team peers
• Less energy in the room
• Team is physically divided

Scrum is about people, not technology.  The subtle but real psychological effects cause by the table cut the effectiveness and communication of the team in half, or more.  It seems a small thing, it’s just a table after all.  In physical reality, perhaps it is small.  But the mental and social structure of the team is decimated.

Maybe you can think of more negative effects of this situation.  It’s all bad.  And it’s just a table.

Does your team room or meeting location have such “elephants” in the way?  Are the chairs too inviting?  Is the lighting wrong?  Assess your environment to from the team cohesiveness point of view and eliminate the physical “elephants” that distract your team from the best agile experience possible!