Leveraging the Team for Good PDPs (if you need them)

I am currently working with a relatively new Scrum team (5 Sprints/weeks young) that needs to rewrite their Personal Development Plans (PDPs) in order to better support Scrum and the team.  PDPs are still the deliverables of individuals required by the organization and likely will be for some time.  The organization is still in the early days of Agile adoption (pilots) and they are large.  So, instead of giving them a sermon on why metrics for managed individuals are bad, I am going to help them take the step towards Agility that they are ready to take.

The Plan:

  • Facilitate a team workshop to create an initial Skills Matrix;
  • work as a team to develop a PDP for each individual team member that directly supports the team’s high-performance Goal (already established)—
    • in other words, when considering an appropriate PDP per individual, the team will start with the team’s performance Goal and build the individual PDP from there;
  • develop a plan as a team for how the team will support each team member to fulfill his/her individual PDP—
    • in other words, all individual PDPs will be part of the team’s plan for team improvement;
  • Internally publish the plan (share with management).

I’ll follow up with another post to let everyone know how it goes.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Inception: Facilitating Innovation Towards Valuable Results

I recently had the opportunity to help facilitate a client’s “Innovation Challenge”.  Basically, the concept is to get a bunch of people in the room, give them a business challenge and see what they come up with.

I have to say that the format of the workshop that I used is heavily inspired by a training that I did recently called Specification By Example by Gojko Adzic.  I strongly recommend this seminar as well as the book.  Another strong influence is The Inmates are Running the Asylum… by Alan Cooper.  The workshop that I have developed is a sort of hybrid approach, with my own flavour added to the mix.  During an early iteration of the workshop, I didn’t have a title and one of the participants suggested “Agile Inception”.  I think that title works in a space where Agile is established and well understood (e.g. hopefully this blog).  At the same time, this workshop can be run with people who have no prior experience or knowledge of Agile and without even mentioning the word Agile.  This is also good in certain environments where people have developed an Agile allergy.

Anyhow, my goal for the day was to facilitate the building of shared understanding of the challenge itself as well as some ways that the organization could innovate around that challenge through conversation and collaboration.

From the opening remarks it became clear that the product at the centre of the “challenge” was actually in deep crisis:  a shrinking market combined with shrinking market share.  The product had generated approximately $18M in revenue in 2009, compared with $10.4M projected for 2014.  That’s half dead in some people’s books.  The clear Goal was to reverse that trend, starting with at least $11M in 2015.  They needed a powerful jolt of life-giving innovation energy to defibrillate their failing product’s heart.

There were no shortage of ideas about how the product could become better & more profitable.  In fact, there were many, many ideas.  Too many, perhaps.  Once we had established our working agreement for the day, we did a Starfish Retrospective exercise to make visible all of the things that the group wanted to keep doing, start doing, stop doing, do more of and do less of.  Many post-it notes were stuck on the board and we left them there as a reminder of all of the things that people were thinking about that could help us to consider how the product and ways of working on it could be improved.

Then we talked about the Goal.  True innovation—that is, tangible, innovative results with clear benefits—requires a group to focus on a single, clear, SMART (Specific, Measurable, Achievable, Relevant and Time-bound) Goal that everyone in the organization understands and is committed to achieving.  Often times, as was the case with the group on Thursday, taking time to establish shared understanding of the goal can seem redundant and tedious (“we already know what the goal is…”).  However, as we learned through the process of working in small groups to re-articulate understanding of the Goal back to the “customer” (the person paying for everyone to be there) this often requires some further conversation.  Indeed, when the groups presented their understanding of the Goal, there were gaps that needed to be filled by the “customer”.  It took less than 30 minutes to discuss, adapt and confirm the Goal with the customer.  The value of this investment of everyone’s time was tremendous.  The conversation made it clear that shared understanding had already been established to a degree and enabled the group to build on what was already there to make the Goal “SMARTer” in the minds of all of the participants.

A single, transparent business Goal helps us to innovate with focus—to create the right thing.  In addition, we need to develop a single Persona—the ideal, “imaginary” user of the product.  The larger group broke into smaller groups for the subsequent discussions.  The groups worked separately and generated a the details for a few personas.  All 3 personas added value to the conversation.  The Persona of “Lisa” was particularly compelling to the “customer” because she had a clear goal of her own and through innovation, her goal could be aligned with the overall business Goal to create a powerful, “new” product that just might reverse the downward trend.

The next step in innovating with focus in order to generate the best ideas possible: build shared understanding of how Lisa can pursue her goal through her experience of the product in order for the business Goal to be achieved.  In other words, Lisa needs a story.  Her story needs a beginning and an end (for now, until the next story) and all the stages of her journey need to be integrated into a coherent whole.

The last step was for the groups to brainstorm and come up with different ways that the product can deliver Lisa’s story in order to realize the Goal.

I wish I could say more about the really cool ideas that the group came up with, but I am erring on the side of caution when it comes to protecting my client’s competitive advantage.

To wrap up the session, we took a quick, anonymous gauge of how confident the participants felt about achieving the Goal.  Of the 13 participants, two gave their confidence a score of 8/10, six gave a score of 7/10, four scored themselves a 6/10 and one was a 3/10, for an average of 6.5/10.  Not bad, but clearly some work still to go.  So what’s next for them?

Next steps:
  • Get the technical folks involved in the conversation (ideally, they are there from the beginning)
  • Build an increment of their solution
  • Review
  • Continue the conversation and collaboration to build shared understanding 
  • Re-gauge the confidence score
  • Iterate  
  • Repeat 
  • The likelihood of achieving the Goal increases with every iteration

 

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Real Agility Program – Execution and Delivery Teams

In a recent post, Mishkin outlined the Leadership Team component of the Real Agility Program.  While the Leadership Team track focuses on developing leadership capacity for sustained transformation, The Execution track focuses on launching and developing high-performance project, product and operational teams.  This track is the one that most of our clients use when they run Agile pilot programs and is a critical component of getting quick wins for the organization.

Groundbreaking works such as The Wisdom of Teams (Katzenbach & Smith), The Five Dysfunctions of a Team (Lencioni) and Drive (Pink) have served well to distill the essential requirements of high-performance teams.  Scrum, Kanban, and OpenAgile are proven frameworks that optimize the value of teams and create the necessary working agreements to help teams reach that high-performance state.

The Delivery Team track of the Real Agility Program creates new, cross-functional, multi-skilled, staff-level teams of willing individuals.  These teams are responsible for delivering value—business results and quality.  Individuals are committed to the performance of the team and the organization.  Teams develop the capacity to self-organize and focus on continuous improvement and learning.  A team is usually composed of people from various roles at the delivery level.  For example, and IT project team might be composed of people whose previous* roles were:

  1. Project manager
  2. Business analyst
  3. Software developer
  4. Tester
  5. Database developer
  6. Team lead
  7. User experience lead
  8. Intern

* These roles do not get carried into the new delivery team other than as a set of skills.

The track begins with establishing pre-conditions for success including executive sponsorship, availability of team members and management support.  Team launch involves a series of on-the-job team development workshops designed to enable the teams to create their own set of values, working agreements and high-performance goals.  Teams are guided in the creation of their initial work backlogs, defining “done”, estimation and planning and self-awareness through the use of a collaborative skills matrix.  The teams are also assisted in setting up collocated team rooms and other tools to optimize communication and productivity.

Qualified coaches assist the teams to overcome common issues such as personal commitment, initial discomfort with physical colocation, communication challenges of working with new people in a new way, management interference and disruptions and appropriate allocation of authority.  This assistance is delivered on a regular schedule as the team progresses through a series of steps in the Execution track process.  Usually, these steps take one or two weeks each, but sometimes they take longer.  A team that needs to get to a high-performance state quickly might go through the entire program in 10 or 12 weeks.  In an organization where there is not the same urgency, it can take up to a year to get through the steps of the track.

The coaches for this Execution track also help management to resist and overcome the strong urge to manage the problems of the teams for them.  In order to develop through the stages of team development, teams need to be effectively guided and encouraged to solve their own problems and chart their own courses towards high-performance.

The goal of the Execution track of the Real Agility Program is to help the team go through the stages of forming-storming-norming and set them up to succeed in becoming a high-performance team.  Of course, to do this requires some investment of time.  Although the Execution track is meant to be done as on-the-job coaching, there is a 5% to 20% level of overhead related to the Real Agility Program materials themselves.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

“Meet: Scrum”, the Diagram

Recently, in my work helping teams to learn and implement Scrum, I have deliberately not been using diagrams.  Having participants create their own ways of describing Scrum based on their own understanding is often a much more powerful approach to learning than showing them a diagram.  If you give someone a map, they tend to assume that all of the exploring has already been done.  If you give them a space to explore, they tend to create their own maps and provide new knowledge about the space being explored.  Maps and diagrams do serve a purpose.  They are useful.  What’s important to always keep in mind is that they should not be regarded as definitive but rather as one  contribution to a body of knowledge that can and should grow.

Anyhow, this isn’t intended to be a blog post about diagrams but rather as a post sharing a diagram that I have created.  One of the participants of a Scrum training that I recently facilitated asked me for a diagram and I said I would find one for him.  All of the other diagrams out there that I could find didn’t exactly convey my own understanding of Scrum.  So, I decided to create my own.

This is the first increment.  I am open to feedback and I look forward to finding out how this interacts with others’ understanding of Scrum.

ScrumDiagramTravisBirch

You can download it at this link: Meet: Scrum.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Scrum Team Assessment – Official Launch

Hi Everyone,  I don’t do announcements on here too often, but I wanted to let everyone know about the official launch of our new product: the Scrum Team Assessment – an online tool for your team to get a report on how well they are using the Scrum framework… and most importantly, helpful recommendations on how to improve!  This is a fully automated Scrum maturity assessment tool!

The Scrum Team Assessment is based on the years that I and two other coaches (Paul Heidema and Travis Birch) have been working with Scrum and Agile teams to improve business and technical results.  The Scrum Team Assessment is a joint effort that has resulted in a fully automated virtual coach for your team.

The analysis is both statistical and expert-system based.  This means that the report has basic information about how the team is following Scrum, and, more importantly, clear how-to advice to get your team to make improvements.  There are “quick wins” which are easy but will have a significant impact as well as long-term recommendations that are often harder, but will drive your team to a high-performance state.

The Scrum Team Assessment includes a survey of about 100 questions that focus on seven broad categories:

  • The team’s environment
  • The basic Scrum process
  • The Product Backlog
  • Team Membership
  • ScrumMastering
  • Product Ownership
  • and Agile best practices

Every team member fills in the survey to help us generate a valid set of recommendations.

The Scrum Team Assessment is $496/team/use (that’s Canadian dollars).  If you have several teams or wish to obtain an enterprise license, please contact us at sales@berteigconsulting.com or +1-905-868-9995.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Just Start!

I have heard many reasons why a new team should wait to start “doing” Agile.  Recently, I was asked to help a group who was struggling to get a Scrum team started.  They had real obstacles to overcome, but waiting wasn’t helping them.

This group was part of an IT initiative to develop a business intelligence program for a large energy company.  The existing processes were highly inefficient and wasteful.  The losses were in the ballpark of $1M/day.  There was a long history of failed solutions.  Needless to say, this was a critical project.

Those of us who understand Scrum well know that the more critical a project is, the more urgent it is to get a team up and running as early as possible.  Unfortunately for this group, there was a great deal of cultural inertia from the IT management holding them back, including chronic distrust between IT & business leadership.  IT management perceived Agile to be a risk and a threat.  They were tolerating it as a “pilot project”.  They wanted to be sure that when Agile failed, they would not be left holding the bag.  Their solution for self-preservation was to insist on getting the architecture of the system in place before the team started to work on features.

The only developer that management trusted with the initial architecture work was also extremely busy working on other projects.  This individual and several other people slated to be on the new Scrum team were tied up working on change requests for a Waterfall project with no clear end in sight.  It seemed impossible to predict when the system architecture work might begin, let alone end.

Meanwhile, the Product Owner was waiting for some new functionality that he could use and show to his superiors—the stakeholders that he reported to in the business.  The program manager, who was the champion of the Scrum implementation, understood Scrum to be the way to succeed.  The first Scrum team was wrapping up on the first project in the new program and the business was happy with the process and the results.  This confirmed his understanding and gave him some traction to move forward.  But he didn’t have authority over all of the slated team members (specifically the sole developer trusted by IT management) to start.

I tried to explore possibilities of moving forward with the program manager.  The conversation went something like this:

TB: Are there some people who are available to start as the team for the new project?

PM: Yes.

TB: Great!  Do you need the star developer on this project or are there other people who have the skills to do the work who could be on the team?

PM: There are other people with skills who are available and who could be on the team.

TB: Great!  Do you have the authority to make that happen?

PM: Yes.

TB: Great!  Can we have the first Planning Meeting tomorrow?

PM: Yes.

TB: Great!  What time do we start?…

One might get the impression from reading that conversation that we were on our way to Sprint 1.  However, as we know, things are usually not that simple.  There were several more obstacles to work through.

(As an aside, I know that some people reading this might be thinking “what about Sprint Zero”.  These guys were talking about Sprint Zero, -1, -2…basically all the way back to Waterfall.  I needed to help them overcome that tendency.)

Below are a few of the other obstacles they were struggling with:

1. The program manager had assigned a project manager, one of his direct reports, as the ScrumMaster to the new Scrum team.  This person was already responsible for (and overwhelmed by) the Waterfall death march project now in perpetual change request mode.

Advice for anyone in this situation:

Find someone else to be the ScrumMaster.  It would be a better use of the external consultant (myself in this case) to serve as an interim ScrumMaster (coach) so that the team could just start, rather than trying to use a traditional project manager who was already overwhelmed by other responsibilities.  In other words, don’t wait for your ideal ScrumMaster candidate to be ready.  In most cases, management’s first choice for ScrumMaster is often not the best one.  If you do not have an experienced coach to serve as interim ScrumMaster, then the best thing to do is hire someone specifically for this role.  Again, it is better to just start than to wait for this new hire.  If you have to wait for the new hire, someone from the team should just volunteer and learn on the job until help arrives.  Even that will give you far better results than waiting.  Just start!

2.  The project manager who was assigned as the ScrumMaster was assigning Product Owner responsibilities to a business analyst that reported to him.  The “BA” was worried that the Product Backlog was not ready for the team.  The real Product Owner had created a high-level Backlog with items that were most likely too large for the team to complete within the two-week Sprint duration that they had decided on.  The BA was trying to work with the PO, but there wasn’t much reciprocity there, mainly because of lack of knowledge of the business on the part of the BA and the PO’s lack of trust in the BA’s ability to serve as his proxy on the team.  During one of my previous visits over a month before, the PO, BA and a few of the other team members had workshopped the Product Backlog, refining the top “epic” and creating a User Story small enough for the team to start working on and complete in the first Sprint.  Now, that story was lost and forgotten.

Advice for anyone in this situation:

Don’t wait for the Product Backlog to be perfect.  If the Backlog is not ready, use the first part of the planning meeting to identify what the team and the Product Owner can agree on as the deliverable for the first Sprint.  In fact, that is all you should be discussing in this meeting in any case.  With the right people in the room (the whole team) this can be done well enough.  If the team is not able to agree within the time box of this meeting, it most likely means that you don’t have the right people in the room.  For example, there may be a project manager and a BA who want to delay the start of the project because they feel uncomfortable with the perceived ambiguity of the process.  It would be better if these people were not on the team and not in the room.  If the team says something like “we can give you ‘X’ in two weeks” and the Product Owner says something like “good with me”, then make that your Goal for the Sprint and get on with the second part of planning—creating a set of tasks to execute the deliverable.

During the first Sprint, the Product Owner can be working with the team to refine the next items in the Backlog based on what has been learned from the Planning Meeting, which is probably a great deal.  The purpose of the Product Backlog is to realize a great Product.  Don’t wait for a perfect Backlog—just start!

3.  The culture of fear and distrust perpetuated by IT management was pervasive and the team was afraid to make a commitment to a deliverable.

Advice for anyone in this situation

Help people understand commitment as a team capability that develops over time.  Teams are able to make and keep commitments based on historical velocity.  For at least the first Sprint and perhaps for a while after that, new teams will not be able to make firm commitments.  Most teams fail to deliver after their first Sprint.  There is a learning curve to Scrum.  There is a lot of change and a lot of new things going on.  The environment of a new Scrum team is drastically more dynamic and complex than what most people have previously experienced.  It takes getting used to.  People need space to learn.  Help them overcome their fear of failure.  Agile is about failing fast.  Get it wrong early, learn, adapt and change course.  What a young team needs to be committed to is learning what it needs to do in order to deliver potentially shippable product every Sprint.  In order to do that, you need to be doing Scrum.

I started this post by identifying that there are many reasons to delay “doing” Agile. I believe this stems from a cultural dichotomy in our society between “being” and “doing”.  We don’t start doing something until we believe that we are prepared to succeed at it.  We have to “be” ready before we can “do”.  This is a false dichotomy that Agile is designed to help us overcome.  Another dichotomy is success vs. failure.  The only real failure in Agile is the failure to learn and improve.  Even the notion of “failure to deliver” is misguided.  The real failure is not learning to deliver.  In order to “be” Agile, you need to be able to fail.  In order to “fail” at Agile, you need to do it.  By doing Agile and failing, we learn to be Agile.  There is no other way.

So, please… just start!

 

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Building Capabilities for High-Performance, Part 1

This is my first crack at a series of posts intended to document reflections, insights and experiences that have been generated over the past several years at Berteig Consulting in our work helping organizations to transform with Agile methods and approaches.

The most recent iteration of our collective practice is the Real Agility Program.  The Program was created as a flexible yet systematic process for developing high-performance teams.  The Program involves assessments, training, leadership and delivery teams coaching and internal coach development for teams and organizations that want to transform in order to become hyper-productive, lean and robust.

A central tenet of the Program is that teams are organic in nature.  They are living systems that grow and develop in the right conditions.  They also develop in stages.  The Real Agility Program addresses the natural stages of team development with a sequence of steps or “sections”.

Much like a seed, a new team has the latent potential for developing into a complex organic system of high-performance capabilities.  Capabilities of high-performance start out as a simple set of attributes and grow in complexity and strength over time.  Capabilities to carry out more complex activities are built onto capabilities for more simple activities.  Little by little, high-performance can be realized in this way.

Something that most teams need help with early on, particularly if they do not already possess a growth mindset, is overcoming the false dichotomy between theory and practice.  An indication of this is when we hear people say things like “well, that makes perfect sense in theory, but it’s just not practical for us.”  Or “we need help to put that theoretical idea into practice in our own reality”.  This reveals a mindset that conversations around concepts and ideas are only valuable if they can be implemented immediately in a measurably beneficial way.  The desire for technical recipes is understandable.  They can help with immediate pain relief.  They are not the most effective way to build capabilities.

The Tree of Organic Growth is an exercise that we often share early in the Program and is designed to help teams develop a more integrated mindset and approach to capacity building (very similar to The Tree of High-Performance in Lyssa Adkin’s wonderful book Coaching Agile Teams).  The facilitator usually starts by drawing a simple diagram of a whole tree, including the roots.  Sometimes, simply exploring the concept in a conversation serves the purpose just as well.  The team is asked to identify values, concepts, principles, qualities, skills, attitudes, habits and knowledge that are already present on the team that will serve as roots for building capabilities of high performance.  The conversation is not merely a nice, (“fluffy”) theoretical stroll in the proverbial park, but a critical aspect of the hard work of re-shaping thought, which in turn re-shapes reality.

Let’s look at an example of the aspects of building a specific capability.  A well-known Agile capability of high-performance is the self-organization of the team.  On one level, it starts to happen as soon as a group of people come together to accomplish something and no one person is identified as the “boss”.  Without certain capabilities in the members, however, this can get very Animal Farm in almost no time.  High-performance requires the development of qualities, attitudes, conceptual knowledge & understanding, habits and skills in all members of the team.  For example, team members need to develop the qualities of openness, integrity and helpfulness.  Attitudes such as a humble posture of learning and serving the team need to be developed.  Knowledge of concepts such as consultative decision-making and Wideband  Delphi and how self-organization differs from traditional command and control project management needs to be developed.  Good habits and practices such as regularly coming together as a team to reflect and plan are essential for the team to become able to deliver complete increments of high value often.  And, of course, team members will need to learn skills in terms of communication and collaboration, as well as other technical skills that may have previously been outside of their formal roles.

Furthermore, everyone can develop in any of these areas of any capability at any given time.  Just like in any organic system, capabilities of high-performance benefit from constant nourishment, feedback and reinforcement.

Growing a high-performance team is a complex process that requires a great deal of effort, patience, time and a supportive organizational environment that will allow for all of these aspects to develop on a team.  It is an investment in people as much as it is a business decision.  There are no shortcuts or formulas, but with the right conditions, every team has the potential to develop capabilities of high-performance.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Reflections on Agile Business Leadership

From push system to pull system thinking

One of the disconnects holding teams back the most in an organization embarking on an Agile transformation is the lack of will and perhaps understanding of vision on the part of the business. The required shift in thinking is from a “push system” to a “pull system”. Historically and still culturally, most organizations, even those claiming to be ‘Agile’ are very much push systems. The business folks in client services – VPs, Directors, sales people, etc. seem to make time (deadline) commitments to clients on behalf of teams and then the teams are given the deadlines to finish the work. Sometimes, the deadlines are decided on in consultation with particular individuals on the teams and very rarely, if ever, with the actual teams themselves. In any case, the fact that the business is almost entirely deadline-driven is the centre of the push system. Deadlines push or drive everything else. Deadlines are fixed and often considered non-negotiable. Deadlines are a taboo subject – it is considered a waste of time to even discuss them because they just don’t and won’t ever move. The general attitude is that if we try to move deadlines, we put the entire business at risk because our clients will drop us and turn to one of our competitors who claim to be able to promise and keep deadlines. If we lose our clients, we lose business, we lose money and it potentially puts us all out of jobs. What this exposes is not only a push system driven by deadlines, but a culture that is actually driven by fear. The not-so-implicit message is that if you miss a deadline, you might lose your job, so you had better do whatever it takes to not miss the deadline. Or else. Push and pull systems and mentalities are like oil and water – they don’t mix. In Agile, there is no place for fear of failure. Rather, teams must be allowed to fail (miss deadlines) and learn from their failures (plan better).

Why quality, not time/cost or scope is non-negotiable

The “make the deadline or else message” is couched and clouded by other talk. The main excuse is to blame the client, as noted above. “That’s just the way our clients work, the way the market works”. Of course, such an excuse contains a kernel of truth. Without a true understanding and embrace of Agile, the idea of not meeting deadlines and the perceived consequences can be truly scary. Generally, there is an understanding from the business that the productivity of teams may drop somewhat as they progress through the storming stage. What this translates into is a difficult discussion with clients around delayed delivery. It is tolerable in that it is temporary. “Once the teams get up and running, we can go back to meeting our deadlines, and even be able to deliver early because Agile is supposed to be faster.” But the benefits of truly adopting Agile are much more powerful than this.

Understanding the true business value of Agile

What needs to be understood is the true business value for investing in Agile processes and practices – how it may add cost and time to the initial development Cycle, but how it saves both the business and the client tremendously on technical debt and support long-term. This needs to be understood and championed by the business in order for the organization to become liberated from its enslavement to the push system mentality. At the heart of such a mental liberation is the wholehearted adoption and commitment to the Agile/Lean principle that quality is non-negotiable. The investment in Agile processes and practices is essentially an investment not only in quality, but in continuous quality improvements towards the goal of being able to frequently deliver products of increasing relevance and quality (value). The ability to ship frequently allows for sustainable growth. All of this is made impossible by the deadline-driven push system mentality/culture of fear.

The urgent need for slack

One of the first things that a team needs in order to focus on continuous quality improvements is slack so that it can learn to learn. The first goal of the business leadership should be to facilitate scope and deadline slack for the team. This goal should also be fully and visibly championed by the business leadership. In order to develop the capability to facilitate slack, the business needs to gain knowledge around the purpose and importance of Agile processes and practices and be able to articulate a strong business case for them. The business leadership needs to develop the skill of educating the team, management and business leadership on the long-term benefits of an Agile transformation – the transformation from a push system to a pull system. The key stakeholders and business leaderships need to possess the courage to engage in difficult conversations with management and clients who may be upset by the short-term pain of delays and missed deadlines and protect the team from continued attempts to push work into the team. Perhaps above all, the business leadership needs to develop an attitude of learning – a humble learning posture that allows for the setting aside of preconceived notions, fears and prejudices around what it means to be a good business leader. A leader possessed of this posture demonstrates a learning attitude by stressing first and foremost the importance of creating slack for the team to learn to learn. It is a common pitfall for inexperienced business leaderships and stakeholders to expect Agile to provide solutions for their push system woes, woes that include the broken trust of clients from consistently broken (unrealistic, dreamt-up) deadline promises and the crippling effects of technical debt (the fallout of the former – when scope, time and cost are fixed, quality is compromised).

If the business leadership, with the support of the Process Facilitators and the Transformation Team, is able to foster the organizational will to create slack for the teams, then the teams will have the space they need to truly focus on continuous quality improvements. This is a critical milestone on the path to realizing the true, measurable benefits of Agile. Although the support of others is needed, the business leadership is in a unique position benefitting from an intimate relationship with both the needs of the business as well as the daily life of the team.

Why the business leadership needs to own the process

The first way that the business leadership creates slack for the teams is by championing the process. In OpenAgile, like all other Agile methodologies, there are key features of the process the purpose of which are to give space for new teams to begin to make the often seemingly inconsequential, yet ultimately critical first steps towards continuous quality improvements. One of the most obvious of these features is the Agile team meetings. In the early stages of team development, organizational understanding and will, the OpenAgile meetings (particularly the Reflection and Learning aspects of the Engagement Meetings in OpenAgile) can easily be discounted as an obstacle preventing the team from getting the “real work” done. What is often forgotten under the pressure of deadlines is the fact that in order for a team to be able to learn to make continuous quality improvements, it needs to develop the capability of systematic (frequent & regular) inspection and adaptation of the way that it works. It is easy to save on the short term pain of perceived non-negotiable deadlines (meeting deadlines at all cost = success) by compromising on investing in the process, especially when the team is still learning to learn and the effectiveness of the meetings is not yet apparent. When the team and the organization have an expectation of Agile as something that fits into the push system and allows for a team to function better within such a system, it can be hard to understand how spending time in a kind of meeting that the team doesn’t seem good at yet can be of any value. This is where the business leadership needs to stand firmly behind the process. The team needs the meetings – the space to reflect, learn and plan – in order to learn to become more effective at making continuous quality improvements – a critical feature of an effective pull system. Without the meetings, the team will never develop this critical capability and as a result, will never become an Agile team. Instead, the team will revert back to getting the “real work” done with all of the quality problems crippling the organization and which led to the decision to adopt an Agile framework in the first place.

Why the business leadership should care about burn-down

Another key feature of the process for the business leadership to understand and champion is the concept of burn-down as represented by the burn-down chart of an Agile team. Agile doesn’t care about how much work the team gets done. It assumes that the team is doing valuable work and getting things done – in other words, that the team is managing itself and working towards its goals and commitments. There are no tools in Agile for an individual, least of all the business leadership, to measure and manage how much work the team is getting done. Agile acknowledges the reality that real (sustainable) productivity cannot be forced on any team. Instead, a team grows its productivity at a sustainable pace when it is given enough slack to do so. The team makes a plan at the beginning of the Cycle based on what it understands about its capacity, works towards that goal throughout the Cycle and hopefully delivers valuable results at the end of the Cycle. By learning to apply the process of continuous improvement, quality and productivity go up hand in hand. That is the essence of the pull model. Through all of this, the team manages “how” it gets work done. The productivity of a team can be measured, but the burn-down chart is neither an appropriate nor effective tool for measuring the productivity of a team. Instead, burn-down provides one specific measurement and ONLY this one measurement: WORK REMAINING (in order to achieve the goal/commitment of the current Cycle). It does not and cannot tell you how much the team got done and even less so the whys and hows of the output and productivity of the team during the Cycle.

So what is the purpose of burn-down and why should the business leadership even care? If it can’t be used as a tool to measure the productivity of the team (in other words, if it can’t be used to manage the team) then what importance can it possibly have? These are typical questions of teams and individuals that are coming from a traditional project management, i.e. command & control, i.e. “push” system mentality. Understanding the purpose of burn-down depends on the ability to make the shift from the push system paradigm to the pull system paradigm. In a push system, burn-down is nice but somewhat irrelevant. For an organization committed to an Agile transformation (towards a pull system of self-managed teams) it is an invaluable launch pad for powerful conversations that live at the heart of continuous quality improvements.

Commitment to the business requirements come from the Agile teams

When a team decides on a plan for a Cycle of work, the plan is a commitment. This is a critical step in the Agile process. It is only after a unanimous commitment from the whole team that the team begins to work on the plan. If any individual team member feels hesitant about the work in the plan, tasks and potentially even Value Drivers should be removed until everyone is comfortable making a commitment. When the business leadership is telling a team what the plan is, then it is not the team’s plan and therefore it cannot be a team commitment. This is not only an inappropriate use of authority, it is also breaking the Agile process. Moreover, when a plan and therefore a commitment is forced onto a team, the team cannot be held accountable for failure. Worse yet, the team will never learn to plan. If a team is not able to plan, then it is not able to make commitments. If the team is overwhelmed by an overly-ambitious, management-forced plan, it will not learn to evaluate its capacity and apply that knowledge to long-term planning and project estimates. It will not learn to make meaningful quality improvements and reflect on its progress. It will not learn to self-manage or self-organize. The purpose of burn-down is to establish commitment velocity. In other words, the amount of work that the team can truthfully expect to complete during the Cycle when it is making the Plan. The difference between the number of tasks in the Cycle Plan and the number of tasks remaining at the end of the Cycle gives the team its commitment velocity. Commitment velocity is always based on minimum historical velocity. The team uses commitment velocity to make a Cycle Plan containing no more than the number of tasks represented by its commitment velocity. This allows the team to spend just the right amount of effort and time on planning and allows the team slack to focus on the truly Agile work of learning and continuous quality and process improvements. Over-planning, especially when it is wedded to over-committing or even worse, non-committing (a common push system mentality pitfall forced onto teams by the business leadership) leaves the team in a state of dependent on daily micro-management and can completely halt the progress of a team. Not to mention that this is a flagrant violation of Agile values (truthfulness, responding to change over following a plan) and principles (sustainable development). Such compromises to foundational Agile values, principles and processes may produce desired results in the very short-term, but the long-term costs can be crippling to teams and organizations. The wasteful activity associated with team dependency on micro-management is what often leads organizations to the accumulation of technical debt that places them in dire competitive disadvantage and desperate need for Agile transformation in the first place. If an organization misses out on this golden opportunity, teams can become demoralized and innocuous to the Agile practices and the promise of an Agile transformation can quickly erode.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I attend every Sprint Planning meeting in person

This rule of Scrum aligns with the Agile Manifesto principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”  In-person attendance of all Scrum Team members allows for the plan to unfold with minimal communication overhead and for the team to keep the meeting within the short time-box.  In-person attendance also allows the team to effectively collaborate in the work of creating the plan. The efficiency and effectiveness of the Product Owner’s presentation of the Product Backlog is optimized as well as the Development Team’s ability to collaboratively assess and select what it can and will accomplish in the Sprint. It also allows for everyone to be clear about the Sprint Goal and why the Development Team is building the increment. In-person attendance also allows the Development team to efficiently and effectively come to a decision as to how it will build the increment of functionality. In-person participation of all team members also increases the likelihood that the team will create the right design for the increment.  If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the planning becomes compromised. Compromised collaborative planning yields compromised collective ownership. The successful delivery of the Sprint Goal requires full commitment on the part of the whole team. Lack of in-person participation increases the likelihood that the team will fail to deliver on its Goal because the planning will lack effectiveness. People are prone to estrangement from hazy goals reached through ineffective planning. In-person planning, therefore, is paramount to succeeding with Scrum.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I am a full-time member of that team (no non-Team Member duties)

Scrum is team-focused. Fixation on optimum (individual people) resource utilization is a major obstacles for effective Scrum implementation. Doing Scrum right and deriving the benefits of team-focus that it has to offer requires full-time dedicated membership of all team members. A Scrum team should be delivering the highest value product of an organization. Having team members assigned to other projects at the same time means that the focus on delivering the highest value is being disrupted. Furthermore, a Scrum team needs to be able to establish and maintain a constant velocity from Sprint to Sprint. This is impossible to do if team members are being shared with other projects and/or teams.  Also, there is tremendous waste associated with task switching that is eliminated by this single rule. The hang-ups of resource utilization need to be left behind if an organization is to mature into one that is Scrum team-focused.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I work with only one Scrum team

All Scrum team members must be committed 100% to the Sprint goal of their team. If people are trying to be on more than one team, then they are not able to be fully committed to the goal of either team. This means that neither team can be fully committed to the deliverables of their Sprint Plans. Failure to commit to the Sprint goal results in failure to deliver and a failed Sprint. When people are working on more than one Scrum team, the teams are being set up to fail at Scrum. This rule is often counter-intuitive to traditional project management, which tends to be obsessed with resource utilization. The problem with managed resource utilization that this rule of Scrum solves is the complete lack of commitment that it forces onto the people doing the work. Scrum creates a sense of ownership of the delivery of the whole product in each and every team member when they are allowed to work with one Team.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcing Release of OpenAgile Primer

Berteig Consulting is thrilled to announce the early release of the OpenAgile Primer, version 1.0, now available for download at http://www.openagile.com/TheOpenAgilePrimer.  This release falls 2 weeks ahead of the scheduled release date of 1 December 2009 thanks in large part to the implementation of OpenAgile itself in the creation of the document.

The Primer is intended as an introduction to the methodology of OpenAgile as well as required reading for the soon-to-be released OpenAgile Readiness Knowledge Test.  Successful completion by individuals of the Readiness Test will result in the award of an OpenAgile Readiness Certificate—the prerequisite for OpenAgile Team Member Certification.

The team wishes to thank all those who have generously contributed to the realization of the first version of the Primer and looks forward to collaborating with many more of you in the future.

OpenAgile public course listings have already been posted on the Berteig Consulting website: http://www.berteigconsulting.com.

We also warmly invite you to become involved in the OpenAgile Community through the OpenAgile Wiki:Community Portal.

We will keep you posted as the work progresses.

To learn more about OpenAgile, please visit us at http://www.openagile.com.

Regards,

The Berteig Consulting Team

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Why try to be good?

What motivates human beings to do the right thing?  To do good deeds, to be truthful, to be kind, to be helpful, to try to make the world a better place?  First of all, we have to realize that everything we say and do has an actual, real effect on our environment for better or for worse.  Every time we help someone, or tell the truth, it actually makes the world better in some small way, just as when we lie, cheat, steal or speak unkindly to someone, no matter how small the affront, we actually make the world worse.  In fact, our thoughts, words and actions can really have only one of two basic effects on the world – they can make it better or make it worse.  Period.

There are some powerful cultural forces in our society, most obviously the constant stream of materialistic propaganda through various forms of hypnotic media, that influence the way we perceive our ability to contribute to the betterment or worsening of our environment.  The basic message is that individuals can’t affect any real fundamental change in society (i.e., their environment) and that the best any of us can do is to change our position, rank or class within the permanent structures of our society.  Therefore, “only the strong survive”, “get what you can while you can” and the “pursuit of happiness” have become not only slogans that we live by, but conceptions of human nature that have constructed our social reality.

For example, the concept behind “the pursuit of happiness” is that happiness is something external and fixed that a person has to find somewhere “out there”.  Embedded in this “right” is the implicit message that “average” individuals and groups do not have the potential to exert influence on, and contribute in any meaningful and lasting way to the shaping of the prevailing social order.  Thus, there is always a better neighborhood to live in, a better employer to work for, a better school for your kids to go to, etc.  It disempowers us all from thinking that we can get together and do something right now about our immediate reality.  ”Don’t even bother”, it says, “you won’t be able to change anything anyways – you’re wasting time, effort, and worst of all – money!  Better to lie just a little, cheat just a little, step on your neighbor just a little in order to protect your own little piece of turf.”

Understanding the truth about our reality – our potential to contribute to the betterment of the world – is what will actually begin to motivate us to be good – that is, the fact that our good thoughts, good words, and good actions can and do make the world better.  ”Better” becomes not merely an external pursuit that we fight to get our little piece of; rather, it is an organic, sembiotic process of growth.  For one thing, it requires vision: What would the world be like, for example, if everyone always tried to tell the truth?  Would it really be so bad?  Would human affairs come to stand still?  Would the economy crumble?  Or would it, rather, begin create something new… something better?

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The ScrumMaster Training Interactive Case Study

You have just been hired to be the ScrumMaster for a team at Zysoft Corp. Your boss, Jeremy, hired you because he likes your attitude and because you have been a team lead at a competitor. But you have never been a ScrumMaster before. Jeremy assures you that you will do “just fine! Scrum is simple!” But some of the things Jeremy told you in your interview make you wonder if it will really be so easy…

The ScrumMaster Training Interactive Case Study is the latest learning tool offered by Berteig Consulting. Like a chose-your-own adventure book, you enter into Jeremy’s world and confront real-life scenarios and learn to overcome real-life obstacles.

We hope that you have fun with this and gain some valuable insights into the role.  The tool is still in beta, so we very much appreciate any and all feedback.  Enjoy!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

How the Agile Community Can Contribute to the Betterment of the World

On April 1, 2009 Scott Ambler posted on his blog “a parody of a very serious ethical lapse within the agile community.”  It was an April Fool’s joke – a fake ad for a 2-day agile certification course called “SCUM Certified™ Agile Master, or more colloquially SCAMmer”.  The mock-ad states that

We want to be perfectly clear about this, by taking this ‘certification course’ what we’re certifying is that you attended the course.  It is your choice (nod nod, wink wink) if you wish to present yourself as a professional SCAMmer.  Yes, about 99.8% of course attendees choose to do this, why would you take the course otherwise?

This piece will not be a direct response to Ambler’s joke.  That would be…well, rather foolish.  Instead, what I intend to address here are the concerns raised by his “Parting Thoughts”, which take on a more serious tone and seem to be getting to the heart of what’s really (and understandably) bothering him.

In his “Parting Thoughts”, he states “I believe we can do much better.”  He is referring, of course, to the “ethical lapse” jokingly addressed by his mock-ad.  He goes on to say:

My hope is that this joke has made you step back and think about what’s going on around you. Being a “Certified X”, whatever X happens to be, implies that you’ve done something to earn that certification. If you’ve done very little to earn a certification then at best that’s what your certification is worth: very little.  If you’re involved in a questionable certification scheme, regardless of whatever justifications that you tell yourself you have still shamed both yourself and your so-called profession.  If you turn a blind eye to people who claim to be “certified masters” after doing almost nothing to earn that certification then you too are complicit: As Edmund Burke first said, all that is necessary for the triumph of evil is for good men to do nothing.  I invite everyone in the agile community to read Ethics for the Real World and to stand up and show some integrity.  Enough is enough.

What Ambler seems to be saying here is that for those of us in the agile community to “do much better”, what we really need is to do something about “questionable certification schemes”.  The “something” he proposes is that we should not “turn a blind eye to people who claim to be ‘certified masters’ after doing nothing to earn that certification”.  What he then prescribes to all of us in the agile community is to read a book and to “stand up and show some integrity”.

So I decided to take the challenge… sort of.  What I mean by “sort of” is that I didn’t read the whole book; rather, I followed the link to amazon.com and read the first chapter entitled “Almost Ethical: Waking Up to Compromise”.  I think I got it.

So, let’s say that we can all agree that integrity is a good thing and it would be  good if everyone’s actions were always distinguished by integrity and uprightness.  At the same time, let’s assume for the sake of this blog that we can also all agree that we live in a very complex world that constantly presents us with situations that make it very difficult to live up to such a standard.  Perhaps we may also all agree that in many of these situations, we often fail to live up to the standards of integrity that we espouse and would like to see established in the world.

In Ethics, Howard and Korver identify that “Lying, a form of deception, plays a central role in ethical compromise” and that lying “appears… commonly in ethical thinking.”  They point out that “Most of us are practiced liars.”  They offer the results of one study as evidence of this:

147 college students and community members kept daily diaries of lying.  The students reported telling an average of two lies per day, the community members one.  None thought their lie telling was serious (although none of them asked the people they lied to).

They go on to make the following observations:

If we hold a video camera up to our lives, we may be astonished at the incredible sweep of lies on the landscape.  If we pan that camera to view the lives of others, we see disingenuousness everywhere.  Imagine being in the shoes of the following people, whose stories are based on real events:

  • You are a consultant, and you know your bid for phase one of a project, $300,000, will turn off your client.  You could bid $200,000, knowing your client will soon agree to the extra work and expense anyway.  You are tempted to understate the cost.
  • You are a young engineer, and you can’t get a software test to run as specified before an industry trade show.  Your manager urges you to run past tapes of the test at the show, pretending that it is a live test.  You are tempted to go along.
  • You are an entrepreneur seeking money to fund your new start-up.  You know venture capitalists chop revenue forecasts by 50 percent.  You are tempted to inflate your revenue forecast by a factor of two to compensate for the expected discount.

Whether or not you’ve ever been in these situations, you no doubt have been in similar ones.  Every time, you have probably had at least one very good reason to compromise – and at times you did.  You lied.  You may feel uneasy about it.  You may even be haunted by it.

But you shouldn’t feel alone.  Using compromise as a helping hand in life has a storied, if seamy, tradition.  Even revered leaders lie routinely…

No doubt, subsequent chapters of this book offer helpful advice about how to overcome the temptations to lie that so many of us so often find ourselves feeling.  What I would like to point out, though, is Howard’s and Krover’s insight that lying “has a storied, if seamy, tradition.”  In other words, lying has become an ingrained, normal and expected habit of our culture.  Temptation is one thing, but breaking out of a culture of lying requires a sea change in human morals, standards and codes of conduct.

Now that the immensity of what we’re actually dealing with when we start talking about “integrity” has become more clear – i.e. integrity is a really hard thing to figure out in a complex world that is really messed up – what can we actually do about it?  In other words, is it futile to try to be a person of integrity in a corrupt world?  The short answer to this question is, unfortunately, “No”.  Just like you cannot be a just person in an unjust world.  A brief example will illustrate this fact:  It is almost impossible for any one person living in North America to be able to guarantee that not one article of clothing that they own was manufactured in a sweat shop or by child laborers.  Indeed, most of us can agree that sweat shops and child labor are examples of flagrant injustice.  By participating in an economy that feeds off of their existence, i.e. paying for goods manufactured under such conditions, we are investing in the system that perpetuates the oppression and exploitation of the people whose survival depends on that system.

Being a person of integrity is equally elusive to being a person of justice.  In order to survive in the jungle, you have to obey the laws of the jungle.  So what is the solution?  What can we actually do?  Is it a hopeless situation, this reality of ours?

Indeed, it is not enough for people to just “be good”.  We must also all strive to transform the social environment, structures and institutions that we are a part of in our daily lives.  In other words, it is not enough to be a “good” person who attacks everything that one perceives as being “bad”.  You can’t just decide that you are going to be civilized in the jungle and complain about all the things that are going to eat you and hope to survive.  You also have to contribute to building the civilization that will replace it, contribute to cultivating a new garden.  You will need to find like-minded individuals and work shoulder to shoulder with them and learn to overlook all of their many shortcomings as they learn to overlook yours.

There is another good book that I’ve been reading:  Beyond the Culture of Contest by Michael Karlberg, Associate Professor in the Department of Communication at Western Washington University, whose research and writing focus on the relationship between communication, culture and conflict.  Here is how Karlberg opens his book:

We live in a culture of contest. In western-liberal societies our economic, political and legal systems, as well as many of our other social institutions and practices, are competitive and conflictual.  Surrounding this culture is a culture of protest.  In response to the social and ecological problems engendered by our culture of contest, we engage in protests, demonstrations, acts of civil disobedience, partisan organizing, litigation, strikes and other oppositional strategies of social advocacy and change.

These competitive and conflictual norms have become so ubiquitous that they appear natural and inevitable to many people.  Indeed, conventional wisdom suggests that these social norms are an inevitable expression of an essentially selfish and aggressive human nature.  The prevailing social order, according to this logic, is an inevitable reflection of human nature.  But is a culture of contest and protest really an inevitable reflection of human nature?  Or is it possible that human beings have the developmental potential for either adversarial or mutualistic behaviour? Is it possible that human culture, rather than human nature, determines which of these potentials is more fully expressed?  Is it possible that the prevailing culture of contest and protest cultivates the former rather than the latter?  And if so, what are the implications?

It seems that by taking Ambler up on his challenge, that is, in trying to figure out how to “stand up and show some integrity”, some initial conclusions can be drawn:

  1. Lying is a big, complex problem – a central part of our culture.
  2. You can’t stop the problem of lying by pointing fingers.
  3. Lying is a social problem engendered by a culture of contest – a social norm that is so ubuiquitous that it appears natural and inevitable to many people.  Many would even believe that it is an inevitable expression of an essentially selfish and aggressive human nature.
  4. Overcoming such a powerful cultural norm is not as easy as getting everyone to just read a book or attend a course.

I hope that everyone who reads this finds it to be an attractive invitation to participate in a mutualistic discourse on how we in the agile community can find ways we can work together to contribute to building a better world – a world characterized by integrity, uprightness, justice, truthfulness, prosperity and joy.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail