Now Playing Tracks

Roles By Any Other Name… Would they smell as sweet?

I remember back in high school when my good friend was working as what he called a “petroleum transfer engineer”.

He was a gas station attendant.

Titles are not sexy, usually.  And, they frequently mislabel what we are capable of or what we do.

Let’s face it, titles suck.

No where else is this more true than in Scrum.

The Scrum Team is all three roles:  ScrumMaster, Product Owner, and Development Team.  

All three of these titles are just crappy.


Not the MASTER of anyone.  They are the master of their craft, which is Scrum.  In fact, the ScrumMaster is actually like the servant to the team.  They should have been called “ScrumServant”.  However, after 20 years of using these titles, we are kinda stuck with them at this point.  (Yes, Scrum is 20 years old as of this year.)  

The SM coaches the team and to do so, can NOT be part of the team.  If we think about professional sports, even though the players are highly skilled, best-of-the-best players, they still have full-time coaches.  These coaches aren’t out there on the field doing.  They are observing, challenging, mentoring, teaching, inspiring, helping, etc.  

The ScrumMaster is there to remove everything from the Scrum Team’s path that may impede them from being a high-performing team.  They are the oil in the machine, not the machine itself.  If we look at the Sample Checklist for ScrumMasters by Michael James, a good Scrum Master MIGHT be able to be a SM for two Scrum Teams.  But a GREAT ScrumMaster is a SM for only one Scrum Team; devoting ALL of their time to helping that Scrum Team become GREAT.

Product Owner

The Product Owner is another horrible name.  They don’t OWN the product.  The company does.  They have the financial responsibility to ensure that the product is making money or maximizing cost savings or making the desired efficiency gains.  How they track that is really up to them and sometimes subject to regulations or stakeholder needs.  The Product Owner is CONSTANTLY focused on what will yield the most value in terms of features at any given time.  

The Product Owner is a difficult role to play because there must be a delicate balance between someone who can actually write the Product Backlog Items (often User Stories) but also someone who has decision making authority.  They must have access to “the customer” whomever that might be and also be accessible on a regular basis to the rest of the Scrum Team.  The Product Owner is also a full-time role and can NOT be the Scrum Master or someone on the Development Team.  Again, there can not be the necessary balance between the three roles if someone is serving a dual role.  It just doesn’t work.  I say, let’s call them the “Product Shepherd” because they are the caretaker of the product more than anything else.

Development Team

Another crappy name.  It’s not ALL developers.  It’s ALL the skillsets necessary to ensure that each feature meets the Definition of Done for EVERY Sprint.  If it doesn’t meet the DoD, it ain’t DONE.  Period.  The Development Team has ZERO resources on it.  Let me say that again:  THERE ARE NO RESOURCES ON THE DEVELOPMENT TEAM.  They are called “people” and these people have “skillsets”.  Resources are like coal, oil, sugarcane, pork bellies, orange juice.  They are commoditized.  Can be bought and sold.  AND, when a resource has been used up and consumed, there is refuse which is discarded as garbage while we seek out additional resources.  It’s an ugly picture.   

People are INDIVIDUALS and I read somewhere that we need to be focused more on Individuals and Interactions here.  The Development Team is self-organizing and self-managing.  They don’t need to be micromanaged or cajoled into doing what management thinks they should be doing.  They need autonomy, mastery, and purpose in order to be intrinsically motivated about their work.  (Dan Pink)  They went to school for this.  They can see through the stick and carrot tactics.

Furthermore, the people closest to the work should be the ones making decisions about the work because they are the most informed source there is.  The Development Team might better be called the Delivery Team because what they are doing is delivering features which are valuable, not just meeting the DoD, but delighting the customer all the time.

New Titles

I propose some new, way more sexy titles that would still reflect the nature of what these folks do.  How about: 

  • Uber-Product Overlord  (Product Owner)
  • Technology Wizards  (Development Team)
  • Supreme Ass-kicking Bulldozer  (ScrumMaster, clearing the way for the team)

Ok, maybe too… wishful?

Getting The Most Value From Gatherings, Conferences, And Other Events

I tend to go to a lot of industry events for IT, and specifically, Agile software development.  In fact, I have now been chair, keynote speaker, reviewer and volunteer for many of these and have reprised these roles numerous times.

I have a deep, insider secret that I want to share with everyone who attends events around the world.  This is HUGE so keep it to yourself and really process it.


The event(s) that you attended / are planning to attend are NOT about YOU.

[Take a deep breath]

That’s right.  As difficult as it may be to accept, these events are NOT custom tailored for all of your personal needs.  The events are designed to meet the basic needs of hundreds and even thousands of people.  Even at the workshop or classroom level, it’s not solely about YOU.

Picture in your mind the last time you planned a dinner with your close family and/or friends.  Was it very easy to pick the restaurant? the dates/times?  Did everyone enjoy themselves?  Were there issues, complaints, etc.?  Did you achieve your purpose?

Now try planning an entire day’s worth of meals for that same group of family and friends… and activities to keep them happy for the day.  Now, multiply that by 3-5 days.  Now, multiply that by 600-2400 people… from 36-100 different countries and cultures around the world… at a venue in a country that is outside your own country.

Are you starting to get an idea of the complexity involved with just the logistics portion of planning these events?  Many people I talk to won’t even try to plan events on a smaller scale because it is too challenging, let alone a large scale event.

On the other hand, I hear from many people how they would love to do “event planning”; how cool it is or how “neat” it would be.  I just smile and listen to them describe the shangri-la of arranging the event… from the perspective of someone who likes to plan and go on vacations.  Most people have no sense of the bigger picture and what it takes to coordinate large scale events.

When we solicit feedback from the attendees, I am really saddened to read how much focus there is on things like:  water and coffee supply, available selection dietary restrictions, frequency of breaks, and other logistics related items.

My advice is this:

If you want great coffee, all day long; go to Starbucks.

If you need to eat every 1-2 hours and/or have exotic dietary restrictions; bring a snack.

If you tend to get cold, bring a sweater.

If you tend to get hot, wear shorts.

If you don’t like a session, move on to another one.

If you don’t like any of the sessions, start submitting YOUR topics.

If you don’t like any of this advice and are still unhappy with the event, stop going…


Give some constructive ways to change it that revolve around the content and substance of the event.  But in doing so, don’t dwell on the lower-level needs in Maslow’s hierarchy because as a human being, those needs will inherently dictate what you do, where you do it, and when you do it.  Your body will figure it out.

Instead, think about how many other people are there at the event.  What would be beneficial to the greatest number of people? 

Or, maybe there are topics that are extremely and critically important for a significant number of people. 

Or, maybe if the topic is so narrow in scope, you need to plan your own event with a very small number of those SMEs that represent that niche topic. 

Or, maybe if you are looking for very specific personal advice, mentoring, coaching, etc. you (or your organization) need to hire a coach so that your individual or organizational agenda is met.

When you go to large events, try to take the perspective of the event conveners and staff.  They are busting their asses and brains to please as many people as they possibly can within the constraints they have.  It’s not that they don’t care about you and what you want or need.  It’s more like they have 600-2400 “yous” to deal with. 

If something isn’t meeting your expectations, chances are, it isn’t because the staff didn’t think about it. 

There probably isn’t all-day coffee and water because the really nice venue (did you notice how nice it was?) wants to charge about $130,000 for that service.  Are you willing to pay an extra $200 on your registration to have coffee and water all-day, each day?  That’s about $67 / day for a 3 day event or about 10 high-end Starbucks drinks / day.

Not everyone wants coffee.  Are you willing to pay that much so that the coffee drinkers can get their fix?  Personally, I am too focused on learning and interacting to worry about the other things.

Want coffee?  Go to Starbucks. 

Or, your favorite local coffee shop.

Or, just go to the venue restaurant and order a coffee to go.  Win-win.  You get EXACTLY what you want.  ;)

We are serving hot, steaming, rich, full-bodied conversations, talks, and workshops about Agility.

My goal as an event convener is to take you out of your comfort zones a little bit; to whet your appetites and make you hungry from an intellectual perspective. 

From a physical perspective, I just want to make sure we are reasonably meeting your minimum biological needs so that you can sustain that brain of yours to absorb, think, feel, express, etc. 

I love, absolutely LOVE, when someone comes to me and says something like “…there was this one moment when you were talking about the butterflies and you mentioned that you would not be amongst them because you aren’t ‘pretty’ enough.  It had a bit of a chilling or closing effect to me, even though I know you were trying to be funny.  I thought ‘Well, Daniel is a nice looking guy.  If he doesn’t feel like he is attractive enough to be a butterfly, then I definitely am not eligible.’”

That is useful to me.

When someone complains about the venue, I get really bored.  If there is a fire, pull the fire alarm and dial 911 (or similar emergency number).  Otherwise, maybe just try to get engaged to the point where you don’t notice those things?

I am not planning these things to be little vacations for you. 

I am hoping they will be deep and meaningful experiences for you that will help you to grow and will last a lifetime.

All that said, hope to see you in Phoenix.


The Life Celebration Backlog

There’s a bunch of stuff I want to do and experience before I check-out.

That sounds a little morbid, right?

Which is why I am not going to call it a “bucket list”.  I am calling it a “Life Celebration Backlog”.  It’s really an ordered list of stuff which I will periodically refine so that the highest value items at any given moment are at the top.  Much of what drives this will be accessibility and availability, not just desire.

For instance, if my work or other professional activities suddenly have an opportunity for me to visit Cape Town, South Africa, then that would jump up to the top of the list ahead of things that I would have to pay for or pursue myself.

Ultimately, there is just too much I want to do in life and a limited time to do it in.  There are some things on the list that are “must have” and others which I can live… or rather die… without.

Definition of Done - User Stories

The “Definition of Done” is a fairly popular (and sometimes emotional) topic out in the Agileverse.  It seems everyone has an opinion on the matter, ranging from “it depends” to “let the teams decide” to a meticulously designed set of business rules and criteria that account for every possible scenario. And as more organizations adopt Agile practices (and, specifically, Scrum), they seek to leverage guidance on this topic from those who have already blazed the trail.


Why is this such a complex topic? One reason is that the word “done” is overused. We must distinguish between different contexts of “done,” which can be applied at the story level, epic level, release level, product level, and so on. In each case, the meaning of “done” has different criteria. For the purposes of this article, we are only going to look at the “done criteria” for a Product Backlog Item (aka PBI or User Story).

Another aspect of the problem with done is perspective. The word “done” is often used to mean “complete” as in the Development Team saying: “We are done with this story.” It is also used to indicate “acceptance” as in the Product Owner saying “This story is done.” I typically teach and coach it this way: Don’t say “done.” Instead, use “complete” and “accepted” for more specific indications of status.

Thus, we define two aspects of the Definition of Done - Completion Criteria and Acceptance Criteria:


The Completion Criteria are summarized as follows:

  • “Code Complete” – as defined by the organization/teams
  • “Unit Tested” – as defined by the organization/teams
  • “Peer Reviewed” – as defined by the organization/teams
  • “QA Complete” – as defined by the organization/teams
  • Documented (As needed; determined by the Scrum Team through tasking at beginning of Sprint)

The Development Team determines when the Completion Criteria have been met with the guidance of the ScrumMaster.  At that point, the story is considered “complete.”

The Acceptance Criteria can be summarized as follows:

  • The list of expectations for a specific Product Backlog Item as defined by the Product Owner prior to the beginning of a Sprint
  • The Product Owner may initially define these alone but eventually enlists the help of the Development Team and ScrumMaster
  • For cases where Acceptance Criteria are not clear, a Spike User Story will be used to define the problem and Acceptance Criteria for a Product Backlog Item to be completed in a future Sprint 
  • The entire Scrum Team must agree to these Acceptance Criteria by the end of the Sprint Planning meeting
  • Minor changes to the Acceptance Criteria once the Sprint is underway as long as there is formal agreement between the Development Team, ScrumMaster, and Product Owner
  • When the Development Team believes these Acceptance Criteria have been met, the Product Backlog Item is ready for a Product Owner review (Demo), which occurs throughout the Sprint
  • The review (Demo) of each PBI should not be left until the very end of the Sprint

The Product Owner officially determines when these Acceptance Criteria have been met. At that point, the User Story is considered “accepted.”

This approach provides a framework that is modular and can be adaptable around the definitions of “Code Complete”, etc., but clearly delineates the roles and responsibilities associated with delivering and finalizing work on features.

If a particular organization is striving toward 100% automation of functional tests that become part of a holistic regression test suite, then “creating automated test scripts” would be expressed in the “QA Complete” criteria.

Further, one group might agree on what “peer reviewed” means but not the “QA complete” criteria. Using this modular definition, each group can customize these definitions to suit their team’s specifications.

As part of this exercise of defining “Done” I have also identified the different stages at which events occur in terms of the Definition of Done:



The first column defines the Scrum Activity during which the action item in Column 2 takes place.  Column 3 identifies which role(s) are chiefly responsible for the action item.

On many of the teams I have coached, where there was a highly contentious relationship between the Product Owner and Development Team, this diagram has helped to sort through who was responsible for what and when. This, along with a well-defined definition of “Done”, set expectations and the conflict was neutralized.

Each organization (and team) must come to consensus on what the “Definition of Done” means for their particular projects/products at various levels (story, sprint, release, etc.). In the next installment of this series, I will explore what the “Definition of Done” means at the Sprint level.

SAFe SPC Training: A Reflection


I recently attended the Scaled Program Consultant (SPC) training with Scaled Agile Academy in Washington, DC.  The instructors for the class were Alex Yakyma and Rich Knaster.

Several others in the Scrum community have provided commentary on their experience in SAFe training; namely Ron Jeffries and Peter Saddington.   I have not reviewed these critiques as yet because I wanted to provide my own, unbiased perspective.  I don’t intend for this write-up to be all-inclusive.  Rather, I will share some key points, which stuck in my mind.

SPC Class

The first three days of training were primarily lecture with more than 500 slides.  There were several breakout sessions also during those first three days.  The training was 8 full hours each day.  There were about 42 people in my class (7 tables of 6).

My goal in attending this course was to remain as objective as possible and to fully listen to what was being presented rather than to argue every point where I experienced cognitive dissonance about the subject.  I put many questions on the Parking Lot for later, took copious notes, and recorded the lectures so that I may refer back to what was actually said in class. 

On a few occasions, I did feel the need to interject because something was said that was so blatantly incorrect or inflammatory that many folks in the class turned to me to see what I would say.  I had identified myself in the beginning of the class as a CSC and CST.  I want to be clear that Alex and Rich are solid instructors and good guys in general who are genuinely trying to help people.  I have a lot of respect for what they are doing.  However, I see benefits and detriments in the course material, approach to instruction, and in SAFe overall that I want to share so that folks have various perspectives to consider.

Throughout the training, there were many references to true agility presented; which was surprising to me, since the SAFe process diagram leaves me with the feeling that this is one of the most heavyweight methodologies in a long time.  Many of the same sources were cited and statements made that CSTs (including myself) have been making in our CSM and CSPO training for many years.  For instance, Donald Reinertsen is noted as being Dean Leffingwell’s inspiration and source for creating SAFe.  There are also quotes and references to: Jeff Sutherland, James Coplien, W. Edwards Deming, Adam Weisbart, Rachel Davies, Taiichi Ohno, Takeuchi and Nonaka, and many others.  In fact, there is little that is NOT included in the SPC training course in terms of mainstream Agile knowledge.  It’s somewhat overwhelming and indiscriminately assembled in a way that leaves me thinking about my grandmother’s test for spaghetti done-ness: throw it against the wall and see if it sticks.


This wasn’t my first official exposure to SAFe.  From 2010 to 2011, I worked at NAVTEQ in Malvern, PA.  We were implementing some of the earlier constructs of what is now called SAFe; such as Release Trains.  Initially, the planning meetings and practices were effective in pulling together product teams across the organization into releases by synchronizing efforts around feature teams. 

Ironically, it was a message the other two coaches and I had been giving to management for over 6 months.  Somehow, the sound of “release train” and “PSI” were catchy enough to make an impact and gain support.  It probably helped that the message was delivered by Dean Leffingwell, who had written Agile books. 

As time went on, requirements such as having everyone attend the PSI planning meetings in person were relaxed and the meetings began to lose their effectiveness.  My contract ended shortly before NAVTEQ announced the closure of the Malvern office.  In maintaining contact with numerous folks from NAVTEQ, I have since heard that they are not only NOT doing SAFe any more but they are not even attempting to be Agile any longer.


For the most part, “Scrum” is recommended as the underlying delivery framework at the team level in SAFe.  I say “Scrum” because there are some significant modifications SAFe makes to mainstream Scrum, which are cause for alarm.  That is, most practitioners of true, well-formed Scrum would consider these changes harmful to Scrum and contra to its successful usage. 

In the Leading Safe Handbook is a quote by Jeff Sutherland:  “Many agile programs struggle or fail.  One major cause of this is simply bad Scrum.”  This seems ironic to me because here the founder of Scrum is saying that Scrum implemented incorrectly is the reason for program failure and then the SAFe Training Course proceeds to define how to use Scrum incorrectly.

In fact, each time Scrum was mentioned by the instructors, it was couched as being inadequate by itself and dysfunctional examples were provided such as “Waterscrumming” or having Development Teams in Scrum which were actually not cross-functional but rather, functional silos.  These examples of Scrum were used to underscore the need for something more; i.e. SAFe. 

I would have liked to have seen Scrum promoted correctly and in accordance with what Schwaber and Sutherland (and all of the CSCs and CSTs of the Scrum Alliance) promote instead of saying in essence:  ”There are problems with every organization that attempts to use Scrum, so we need to accept this dysfunction and build a process that accommodates organization impediments instead of looking for how to remove them.” 

The following are some things about SAFe that attracted my attention during my training.

SAFe can be tailored however an organization wants and needs in order to make it work

As long as I am able to work with a client implementing “SAFe” and we are allowed to tailor it to include the helpful parts and throw out the harmful parts, I don’t see anything really evil or wrong with SAFe here.  What we are left with is doing precisely what I have already been doing for the last 8 years:  looking for how to instill the values and principles Agile and Lean in the culture of an organization so that a paradigm shift toward continuous innovation and customer delight happens.  The net result is that they understand why they are following the practices they choose to follow and not just blindly implementing methodologies.

There are several groups today who are working toward addressing complex adaptive systems by adding additional layers of complexity.  From my perspective, as someone who coaches large enterprise organizations, call it SAFe or DAD or LeSS or whatever makes people feel more comfortable and helps invite their voluntary participation and contribution to real change.  If SAFe helps us get conversations going in an organization where there was no discussion before, then how can that be bad?  The important thing to keep in mind is to keep an open mind.  Once minds begin to shut and fixate on a “simple” solution it usually signals that we have reached the point of stagnation.  When there is no interest in REAL change, growth, learning, etc. then it is usually time for me to move on to an organization that practices the “art of the possible”.

SAFe can not help with the organizational and cultural changes necessary to support itself.  It is only intended to be useful at the Program level.

This point was made numerous times.  It’s the same rationale that is used to fault Scrum; i.e. that it is not an all-inclusive solution and answer for everything.  Here again, as someone who might be interested in implementing and helping clients with SAFe, I am not really able to unless I have the experience, knowledge, and skills that I would need in coaching any organization using any Agile practices.  Again, we are back to me doing what I have been doing with Scrum all along by helping my clients figure out what their culture really represents and any changes that need to occur to support the practices they are trying to adopt; including, choosing the right practices to suit their culture and agenda to begin with.

"It Depends…"

Initially, the instructors mentioned this classic consulting answer as a joke.  However, whenever there was a really tough or specific question asked about how SAFe addresses [this] in practice, the answer was always “It depends…”  By the end of the first or second hour, the joke wasn’t really funny anymore; people were genuinely expecting answers, which, just weren’t there.

And so it would seem that the same flexibility is built into SAFe as there is in Scrum with respect to inspecting and adapting and responding to change.  This is interesting because the SAFe diagram and definition include many prescriptions.  For instance calculating Weighted Shortest Job First, using “Normalized” Story Points, mandating organizational cadence at the Sprint level (4/1) instead of at the release level, requiring that architecture and feature backlogs be treated independently and separately, just to name a few.

If the ultimate answer is “It depends…” then I don’t see that SAFe is adding any value beyond what is already in the toolkit of most experienced Agile coaches.  There is a definite marketing bent toward the middle tier of management since Scrum does not provide a prescription for or limit on what middle management can or should do during an Agile transformation.  In fact, this targeting of middle tier management was made clear on the first day.  There are references made to centralizing some decisions and decentralizing others; i.e. making strategic decisions in business and management and more tactical, delivery decisions at the team level… just like in Scrum.  It’s the classic “what” vs “how” distinction.

ScrumMaster is not a full-time role

Here is a key point in SAFe which clearly promotes dysfunctional Scrum.  The ScrumMaster role is trivialized and treated as an optional role.  I heard from the instructors that anyone on the team can step in when needed to be the ScrumMaster, which prompted me to ask “How does a person who is expected to play both roles (Development Team and ScrumMaster) decide which way they will disappoint the team:  by not finishing the work they have committed to during the Sprint or by not removing an impediment for other team members?  Either way, they are letting the team down.”  The answer was, of course, “It depends…”

The reasoning and comments clearly shows a wholesale lack of understanding of the role.  I asked what their thoughts were on Michael James’ “ScrumMaster Checklist” and it was clear that they had no idea what I was talking about.  The comment back was that it can be helpful as a checklist but that there should still be flexibility in what the ScrumMaster does; i.e. in terms of work on the Development Team.  In reality, the checklist provides support for the idea that ScrumMaster IS most definitely a full time role because it suggests all of the various activities that a ScrumMaster should be doing in order to adequately serve the needs of a typical team. 

There was no mention of the ScrumMaster as a coach to the Scrum Team / organization or as a servant leader or “chief impediment remover” to the Scrum Team.  I would have been slightly happier if they had said that in SAFe, the ScrumMaster is responsible for helping people to understand SAFe and to help coach them through their understanding of release trains, etc.  But alas, there was no talk of helping Product Owners to understand how to break down PBIs or how to accomplish the organizational level changes that SAFe recognizes as necessary in order for an organization to develop its own Agile abilities.  To their credit, the instructors acknowledged the need for a full-time Product Owner.  The ScrumMaster needs to be viewed as a full-time role as well in order for Scrum to work properly.

No Emphasis on a PSI at the Sprint Level

Another missed opportunity in SAFe when compared to Scrum is that Scrum focuses more on value delivery and technical discipline by emphasizing a potentially shippable increment (PSI) EVERY Sprint.  Across complex systems and architectures, this requires careful and deliberate collaboration amongst teams. 

It also forces an organization to re-examine how it has been producing software to date.  As Einstein mentions, “We cannot solve our problems with the same thinking we used when we created them.”  So why are we expecting that we can pursue change, vis a vis Agile adoption, and not attempt new ways of architecting systems? 

End to end slivers of functionality that deliver customer value every Sprint are possible.  It requires a shift in thinking and ability to see what is possible.  These usable slivers of functionality are represented by Product Backlog Items with testable Acceptance Criteria. 

In SAFe, there is no requirement that a team produce anything that is intrinsically valuable to the customer until they reach the PSI boundary along with other teams.  This thinking, then, promotes waterfall within the context of Scrum. 

Teams are no longer required to completely integrate and test during their Sprints.  They can wait until the HIP Sprints for that; discovering only after 5 weeks that there are critical, system wide defects… By delaying value delivery, there are missed opportunities for customer input and feedback with the net result being more inventory, not less.  As the principles of Lean indicate, inventory is waste because it is unrealized value.  Thus, reducing inventory and producing smaller batches is preferable; such as producing a PSI every Sprint.

HIP Sprints

HIP stands for Hardening Innovation and Planning.  In SAFe, apparently, one Sprint every four Sprints is reserved for “catching up” on integration, design, and other tasks which were not completed during the previous four Sprints.  This assessment is based on comments by the instructors and the Leading Safe handbook.  In another part of the training, the analogy of Google 80% time was used.  That is, the team is given an entire Sprint to do whatever they want.  However in yet another part of the training, it explicitly states that HIP Sprints are NOT intended for catching up on testing, integration, and planning.  So, it is not really clear why HIP Sprints are necessary. 

In the case of providing Google 20% time, I would support letting the team pursue this goal.  However, allowing the team to decide how to implement it by promoting self-organization will yield better results than saying “Ok, GO!  Now is your time to be creative.  Hurry up, you only have one Sprint…”  

Leaving integration and testing until the fifth Sprint introduces four Sprints worth of risk in terms of defects and code refactoring work that needs to be done.  If we aim for integration as an ongoing part of development each Sprint with much smaller vertical slices, then the defects we discover can be addressed at a lower cost (for 2 weeks) with less refactoring effort than if we discover these after 10 weeks (during the HIP Sprint).

Architecture Epics vs Feature Epics

As part of emphasizing delivery of customer value each Sprint, we often refer to Bill Wake’s INVEST acronym to remind us of the characteristics of good Product Backlog Items.  The first characteristic is “Independent”.  It is difficult to see how a feature can stand on its own if it can not be built until the underlying architecture to support it is in place.  The idea of emergent design is to develop the architecture WITH the features that provide customer value.  Thus, each customer-facing feature must include in its delivery and construction the very elements which support it. 

Creating an architecture which is separate from the features introduces disparity and fundamentally, additional inventory which delivers zero customer value.  The evolution of emergent design and value delivery is continuous delivery wherein pieces of end to end functionality are fully realized and delivered as they are completed and not held for release.  Several enterprise wide systems are employing this model with a high degree of success today.  Features are coded, tested, integrated, tested, accepted, and deployed all throughout the product lifecycle.

Conway’s Law postulates that an organization will produce software that mirrors its organizational structure.  This further emphasizes the need to have integrated teams who work simultaneously on architecture and functionality with each product backlog item.  Having systems architects who make decisions about the entire system separate from the delivery teams who implement these elements and other teams yet who construct the features perpetuates brittle architecture with many dependencies and barriers to value delivery.


General bias against Scrum and the Scrum Alliance

A statement was made that if an organization hires 10 trainers from the Scrum Alliance, they will get 10 different versions of Scrum; which don’t use any consistent terminology.  This is 100% false.  

Every CST is required by their license agreement with the Scrum Alliance (and the Code of Ethics) to train Scrum in accordance with the Content Outline and Learning Objectives; which map to the Core Scrum Definition on the Agile Atlas website. (  This is for both the CSM and CSPO class. 

An organization who hires 10 different CSTs WILL get  the individual experiences, stories, and wisdom of 10 different trainers as a supplement to Core Scrum.  That is, my stories, which support the need for self-organizing teams, will be different than another CST’s stories that support this concept.  This dynamic provides more rich background and experiences for an organization as a whole to draw from.  Students may also experience 10 slightly different training techniques; although, for a common client, it is not unusual for an agreement to be made that common materials are used amongst all Scrum trainers for that particular organization.

The trend in the CST community has been to employ constructivist didactics instead of dialectic learning models.  That is, we teach Scrum by modeling the class after Scrum and use various different elements of our courses which address different learning modalities; auditory, visual, tactile, sensorimotor, etc.  These are commonly referred to as “Training From The Back Of The Room” (TFTBOTR) techniques after Sharon Bowman’s book of the same title.

I didn’t get the sense that either instructor has ever experienced Scrum as it was intended to work; which explains why there was bias against it.  Perhaps if they had been involved with some successful implementations at the enterprise level, they might have different experiences to draw from.

I also see that the PO certification that Scaled Agile Academy (SAA) is currently working on has the potential to become a directly competing certification with the CSPO from the Scrum Alliance (SA).  If SAA created a ScrumMaster certification, then there would certainly be direct competition with SA.  Perhaps this is part of why they have decided to de-emphasize the role with a later plan to launch this spring boarding off the success of other SAFe certifications.


Attending the SAFe SPC course has provided me with deeper insight into the framework and a better understanding of the intentions of those who are promoting it.  I came away with the realization that many elements of SAFe include what we often do in Scrum with large scale Agile adoption. 

In Scrum, however, we are less prescriptive and do not begin with a final picture in mind of what the organization should look like.  Rather, we seek to understand what the organization is attempting to accomplish and build upon that vision as we empirically gather information and iteratively inspect and adapt upon it.  

In Scrum, we use techniques such as mapping value streams as part of developing a Product Roadmap and elaborating Epics into Product Backlog Items and using a portfolio level Product Backlogs that feed program level Product Backlogs which in turn feed team level Product Backlogs.  However, we keep the emphasis on self-managing teams so that those closest to the work are making the decisions:

"Your firms are built on the Taylor model. Even worse so are your heads. With your bosses doing the thinking while workers wield the screwdrivers, you’re convinced deep down that is the right way to run a business. For the essence of management is getting the ideas out of the heads of the bosses and into the heads of labour.

We are beyond your mindset. Business, we know, is now so complex and difficult, the survival of firms so hazardous in an environment increasingly unpredictable, competitive and fraught with danger, that their continued existence depends on the day-to-day mobilisation of every ounce of intelligence.”

-Konosuke Matsushita

In Scrum, we emphasize more frequent and regular development of value earlier on so that ROI is realized from the very first Sprint.  Using the organizational cadence defined by release trains is merely one way to achieve integration between teams across a complex system.  There are other models that must be considered in order to provide options suitable for various organizations; one methodology does not fit all.

In so far as SAFe is a mutable framework that can be tailored to an organization and adapted as needed, I don’t see issues with conversations starting with SAFe.  It’s not where I would begin the conversation myself.  However, when my clients ask me my thoughts or would like to share their thoughts as they consider pursuing SAFe, I am now more inclined to reason through the different elements of SAFe with them, highlighting the pros and cons and making them aware of other options as well.

As a newly confirmed SPC, I have the ability to train SAFe Agilist (SA) and SAFe Practitioner (SP) courses.  As with any certification and set of practices, if I am training a SAFe course, I will remain true to training what the SAFe learning objectives define.  However, as with any training that I do, I will also encourage my students to think for themselves and make the process serve their organization, not the organization serve the process.  No tool or process should ever replace thinking and communicating.


How Twitter Broke My Heart

I used to love Twitter.  

Now, they have driven me away… forever.

They suspended my account on December 10th.  Haven’t told me why.  Haven’t responded to any of my tickets or Emails.
If they reinstate my account, I might have a change of heart.  It’s difficult to be a supportive fan if you are not being allowed to.

Reluctantly, I may have to write-off 30,000 followers and start all over with another social media channel; one that doesn’t artificially limit the number of followers you can have or the number of people you want to follow and then try to justify it with ridiculous “logic” which defies all logic.

If that account has been permanently banished, then there is no way in hell that I will ever return to Twitter.  Ever.  In fact, I will do my best and call on all the powers of dissuasion that I have to steer people away from Twitter;  not so much out of spite but more by way of public service and care for others.  I can’t consciously recommend a service that is so blatently ignorant to the needs of the customer as Twitter has been.  I feel a duty to share this story so that others don’t get similarly screwed by Twitter.

Maybe they are just too busy with the recent IPO.  (Or, maybe it’s a bunch of IPA that has everyone so disengaged and disinterested in providing a modicum of customer service…)  

Ultimately though, this stinks and I have been patient a nice for long enough now.  

You had your chance, Twitter.  Now I am mad.

You encourage people to follow tons of other users and then you turn around and penalize people for following too man.

AND, I can’t believe some of the shit you allow out there.  All of my posts have been at most PG-13.

So, I am left scratching my head as to what the heinous thing was that I did to warrant a suspension this time?  Perhaps it’s good ol’ censorship of religious beliefs?  Which is funny because the last thing I posted was a picture saying:  ”Regardless of what your background or beliefs are, just wish people well this season.”

I suspect that now, after writing this, I won’t ever be reinstated.


I am not one to kowtow or engage in superficial ass-kissing when I am seething with anger inside.  Initially, I was calm.  I simply wanted to find out why you suspended me, get my account back, and then I would watch out for whatever behavior triggered the suspension.

However, this is idiotic.  Honestly.  I have been an avid fan and support of Twitter for 4-5 years and have brought you countless Tweeters over that time period.  And, this is the thanks I get?

I have Emailed and tweeted to @ginger, @delbius, @twitter, @support, and even @dickc. I even sent a LinkedIn connection request and InMail to Dick.


Not a single word… from anyone.

It violates all of the rules and best practices of customer service and delight that I coach with my clients.  Now, I can add this as a story to my Agile coaching for Product Owners:  ”Don’t be like Twitter.  Here’s how THEY treat people…”

Really sad.

Nordstrom’s Knows What I Want

I had searched my make/model of MacBookPro on Amazon for a replacement battery and after selecting a “brand new” battery at a low price, I ordered it.

When it came, it clearly wasn’t the right model. Disappointed.

I returned it because Amazon Prime is great about refunding your money with zero shipping charges either way.  I wrote a negative review about the product listing itself, because I was disappointed.  

What would have made my experience better was if there were more pictures of the item, maybe with the back of the MBP pulled off to see where it goes and also- most importantly- part numbers.  

The merchant has since included part numbers with all its listings.  

They reached out to me to ask my permission to send me a FREE battery that matches my MBP model.  I was surprised… and very delighted.  I said “Ok, sure.  I really appreciate that.”  I gave them the model number and my address.

I thought to myself: “If they do this, I will update my review or do a new review and say how they went the extra mile for me.  Let’s see what happens.”

The next day, they Emailed me back saying that they don’t carry that model…

And, pointing out how their listings now have part numbers…

And, asking me if there is anything else they can help me with…

And, would I be willing to remove my review or update it based on this latest experience…

I just shook my head in disbelief.

I sent them an Email back citing the infamous Nordstrom’s Tire Return story.  Recounting this story from almost 30 years ago when I first heard it in college, I was inclined to look it up on Snopes.  There is some debate about whether it is true or not and if so, to what degree.

Doesn’t matter.

The story represents what is in the mind of ALL customers.  It is literally a textbook case of ultimate customer service; that is what people want.  At a minimum, customers have a need they are trying to satisfy.  If the need is met, there is maybe a 50/50 chance that they will return as a customer.  

If the customer’s expectation is exceeded, then brand loyalty is strengthened and they will not only be a return customer, they will evangelize the product and brand to others.

If expectations are not met (or worse, negative expectations are met/exceeded in the negative direction) then no amount of additional cajoling will bring that person back to the realm of potential evangelist.

In this case, once the merchant promised to send me a “free, brand new battery that does match my model of MBP”, they should have gone to whatever length they needed to to fulfill that promise; call Apple, go to another merchant, etc.  

Instead, they simply reinforced the initial negative experience that I had with them and worse, they wasted my time, set a new negative expectation, did not deliver, inspired me to write this blog post, etc.

Now, I am done with that merchant…

Well, almost.  I might even update my post with this newly disappointing experience to reinforce my initial negative review.

If they came back and said “Here’s a whole new MBP 17” fully-loaded with software and upgrades, etc.  We will give it to you to make you happy.” I would still be thinking “Check’s in the mail…”

Delight your customers, and they will become your most valuable allies.  Make them mad, and you will be out of business.

Ego: The Greatest Barrier To Knowledge Acquisition

"I am wiser than this man, for neither of us appears to know anything great and good; but he fancies he knows something, although he knows nothing; whereas I, as I do not know anything, so I do not fancy I do."

-Plato, Apology

I recently taught a CSPO class for a private client.  Within the first 20 minutes of the first day, the sponsor of the class pulled me aside and said “You really need to pick up the pace here.  You are starting to lose people.”  I politely acknowledged the feedback and resumed.  

Based on the comments I was hearing and the questions being asked, it was clear that this group was very new to Scrum.  Reading the body language and other non-verbal cues, I saw a different situation than the sponsor had communicated.

At the break, the sponsor came to me again and said “This is all nice and everything, but people are coming up to me to say that the class is moving too slow.  We really need to pick up the pace here.”

Being human, I was very frustrated.  I was ready to walk out of the class.  I hadn’t faced this kind of situation before; i.e. someone (or people) who were so closed-minded and impatient that they couldn’t wait to see what else the class had to offer.  

I took a moment to think and compose myself and I said “Let’s wait and see what the feedback says at the end of the day.  What I noticed when we did the ‘Prior Experience’ activity is a couple people have prior knowledge and experience with Agile.  This is an entry-level certification and assumes no prior knowledge.  So, the foundational level knowledge that is part of the certification is just a review for those couple people.  However, we need to level-set for all the others who have not had previous experience or knowledge.”

Additional comments were made, which I listened to but chose to ignore.

At the end of the first day, I collected feedback about the class using the “What was Good?/What would make it GREAT?” exercise.  As with all of my other classes and many other classes I have observed with other trainers, the feedback was net neutral.  Someone writes “Love the exercises” and someone else writes “Fewer exercises.”  Someone writes “Love the opportunity to learn things as a group.” and someone else writes “Need more instructor lecture and textbook based learning.”  Someone writes “Pace was perfect.” and someone else writes “Make it faster paced.”

I circled back with the sponsor on the second day of class and they admitted that they shouldn’t have made that statement the day before without seeing how the rest of the class was laid out.  I mentioned that perhaps this is why their attempts to implement Agile have not been as successful as they would have liked; because they aren’t being patient enough to allow REAL learning to happen.

During both days of the class, my colleague and I wore name tags so that everyone in the class could remember our names.  At the end of the second day, one of the manager level types who had been complaining about how slow-paced the class was, came up to my colleague and said something like:

"See, what you and… um, your colleague, what’s his name… need to realize is that we here at [xyz corporation] learn 50 times faster than the average human being.  So, you really need to get to the point more quickly in these sessions."

When I heard this, I just thought to myself “Wow, you didn’t learn a damn thing, did you?  Maybe if you had been more focused on listening and having an open mind and less on how much of a genius you think you are, you would have understood the points which the others in the class, who gave us positive feedback, were able to get.  Oh, and I think the ‘average person’ would have probably been able to remember my name, which has been in the Top 10 list of boy names for the United States in the last 50 years; especially after seeing it right in front of their face for two whole days…”

Don’t take my sarcasm as anger.  I actually think this was hilarious, the irony of the situation.  It has given me a great story which has been entertaining for others to hear.

Ultimately, the take-away here is, like the quote states:  The person who realizes that they aren’t really a genius is more of a genius than the one who adopts a condescending attitude toward others based upon their perception of their own superiority.



An “Agile” Experiment

Here’s is an experiment I would like everyone to try:

For one full week, whenever you see or hear the word “Agile” (or “agile”) in a sentence about project management, software, development, etc. substitute “Agile” with the following phrases:

  • …thinking for yourself…
  • …talking to people…
  • …producing things that people want…
  • …looking at what’s possible…
  • …being less of a dick…
  • …solving problems with the simplest solution…
  • …delighting customers…
  • …being a whistleblower…
  • …taking responsibility and initiative like an entrepreneur…

What’s the point of this experiment?  

I am seeing and hearing more and more about “Hybrid Agile”, “MANAGED Agile Development”, “Scaled Agile”, etc. which leads me to believe that most people aren’t getting what “Agile” really means, or rather, the spirit of what the word represents.

Perhaps the Agile Manifesto has become too much of a mantra?  We all can recite the Values.  I have found that many who claim to “know Agile” haven’t seen the 12 “Principles Behind the Manifesto” or have forgotten about them, etc.  However, those also provide more of a clue as to what “Agile” means.

In the above phrases I listed, I have tried to avoid using too many of the “buzzwords” which are becoming meaningless and diluted.  E.g. “collaboration”, “value”, “innovation”, “empowerment”, etc.  These are often tossed around without much thought of what they mean or what the implications are.  People just want the benefits and R without the I.

Did some of these shock you a little bit?  Hopefully.  There is a bit of humor intended there but also, reality.  I am not implying that Agile means “hippie love fest” but it certainly means getting along better with the people you work with and the customers whom you serve.  

Anyone who works serves a “customer”.  You could even view your relationship with your employer as serving your customer.

As you try out this experiment and find that these phrases don’t fit with something that is labeled “Agile”, it’s probably a good sign that it isn’t…


If Restaurants Were Like Hospitals…

If restaurants were like hospitals, you would have a reservation for your meal and arrive on time but they would still leave you waiting in the lobby for over an hour. They would finally seat you at a table and bring out every dish, glass, and piece of silverware you could possibly need.

Then you would sit at the table with no food or drink for another hour or two. The wait staff would come in numerous times to see if there is anything you “need”.

Finally, they would call the chef and tell them to come down to the restaurant to start cooking for you. The chef would fry up something in a pan and then hastily leave the kitchen while the other kitchen staff prepare the remainder of your meal.

And in the end, they would have the check sitting on your table before you are done eating…

Eagle and Dragon

My mind has been officially and completely blown. 

I spent two weeks in a country whose language I could not speak, read, or write.  The people there, in various degrees, were able to speak and read my language.  It was nice in a way to be able to tune out and not understand EVERY conversation going on around me or feel the need to read every sign.

I also found that much of our communication as human beings is universal.  Pointing and pantomiming go a long way; as do smiling, having patience, and simply making an effort to understand something before passing judgment.  I am grateful to all those I encountered in China who had patience with me and welcomed me to their country.

From a tourism perspective, guides in Beijing are very inexpensive it would seem.  I had a driver, guide, meals and attraction tickets included for 800 RMB (about $130) all day.  However, if this is appealing, I would recommend skipping the “tour of a silk factory”, “tour of a cloisonné factory”, “tea restaurant”, and the infamous “Nephew of the Last Emperor’s Calligraphy Studio” at the Forbidden City.  This is where the guide will steer you and where they get kickbacks from stuff that you buy.

Initially, it seems like there are great deals on things.  They won’t haggle, stating that “this is a government shop and the prices are fixed”.  Just walk away.  You can find the same stuff elsewhere, like the Qiamen district in Beijing or Nanjin Road in Shanghai and other areas around the Bund and Yuyuan Gardens.

Prior to spending time in Beijing, the most polluted air quality I had seen was in Milan.  I have heard Mexico City is also very bad.  I haven’t been there.  The locals in Beijing aren’t naïve.  They are all well aware of the pollution situation.  On one particular day, we couldn’t see the buildings just across the street, which was about 30 meters (about 100 feet).

They are also well aware of the population situation.  I hadn’t seen that magnitude of population density… ever.  I mean, sure, in New York, Chicago, Los Angeles, San Francisco, Las Vegas, Rome, etc. there are times during the day when the streets are crowded; the morning rush, lunch time, the evening rush, special events, holidays.  However in China, it is like perpetual rush hour.

On a Friday at actual rush hour, my friend and I were taking a cab back to my hotel from the training venue.  We spent about an hour traveling 1.25 miles.  We were stopped dead on 103 National Road (the Jingtong Expressway).  It was like being on the 5 or 95 freeways.  

After about 10-15 minutes of sitting there, watching others get out of their cars, chatting to one another, my friend said something to the driver, paid him, opened the door and said “Let’s go.”  The driver was pissed.  However, there at the side of the road I could see the Dawanglu subway station.  I had to laugh out loud as I wheeled my rollerboard full of training supplies down the freeway in between the parked cars… It was a scene right out of “Planes, Trains, and Automobiles”.

We were back to my hotel in about 10 minutes.  I asked what the driver was on about and my friend said that he didn’t want to be stuck alone in traffic with no one to talk to.  (I suspect he was also mad he wasn’t getting paid to be there anymore either.)

In visiting the various attractions, I was amazed by the history, traditions, and balance between opulence and poverty, complexity and simplicity, self and community, and various other characteristics; some in harmony, others in sharp discord.

By far, the thing that amazed me the most was how inaccurate all of my preconceived notions of China were.  In America, we generally don’t pay much attention to anything that doesn’t directly involve ourselves or is not touted in the media.  Because I firmly believe that most media is sensationalistic, what we get is a caricature of China, not reality.  I am sure they get the same distorted view of the U.S. from their media.

Meanwhile, the good citizens of both countries are trying to eke out an existence however we can, caring for our families and other loved ones, making friends, celebrating life and reflecting on the condition of humanity.

I am not naïve either.  It is well known that the government is continually watching and monitoring the people (… in both countries.)  It is well known that corruption is rampant (…in both countries.)  There are the rules and then what people actually do to make things work (…in both countries.)  So, what’s different?

Quite a bit, and yet, not so much.  I continually found myself wondering what life in the US might be like with 1 Billion more people and a homogenous culture reaching back 2000-3000 years.  Probably even closer still to that of China.

One of the main reasons I was in China was for the Regional Scrum Gathering, which was a huge success.  Shining Hsiong, Bob Jiang, and all of the others who volunteered did a PHENOMENAL job!!  I know first hand how difficult it is to organize a Scrum Gathering, and they didn’t have a great events firm like Elastic to rely on for logistics.  Kudos to the whole team and speakers!!

China is ready to move forward with Agility.  

It has already been happening.  It will take time.  There will be some resistance.  Old traditions in business will be difficult to change.  Centuries of focus on theory x and Taylor model management are not abandoned easily.  Elaborately hierarchical organizations do not become flat over night. 

But which country am I really speaking of now???  These things could easily be said about ALL countries and organizations around the world when first considering Agile adoption.  Looking at how the society functions in China, from my limited exposure, it seems right on the edge of chaos; doing only what’s necessary, deciding at the last responsible moment, following the rules as a set of guidelines not absolutes, etc.

There are establishments emerging which are uber-focused on customer service and delight, like the renown Haidilao restaurant where the servers are able to exercise complete control over delivering the best experience possible.  

The CSM classes I taught received overwhelmingly positive feedback.  I was surprised.  I thought that the fact that they were primarily in English would have sealed my fate.  The attendees were excited about Scrum, Agile values and principles, and eager to hear more.  It would have been great to have more time for discussion and more examples but that’s the case with every class.  We made the most of the time we had.

Overall, I must say 谢谢! (THANK YOU!) to everyone whom I met and came in contact with during the 2.5 weeks while I was in China: the random people I encountered while exploring the sights, the Gathering attendees and organizers, the attendees in my classes, and everyone else whom I might have missed mentioning.  I was amazed at how friendly and hospitable everyone was.  It gave me hope for the world of work and the world in general.  I felt very welcome and well-cared for.  What’s more, I felt safe.  I wish I could say the same for walking around alone in downtown Detroit or L.A. or NYC or even Philly.  

I have made some great friends during my stay and I hope we can keep in touch.  I look forward to the next opportunity I have to visit and the adventures that await…



Allow yourself to be amazed…

I arrived in Shanghai this afternoon a little hot and tired.  With the heat, humidity, and my hair being on the longer side than usual, I decided “Why  NOT go to a shop where the people have no idea what I am saying and let them cut my hair???

I think I said three things:  long, short, and thank you.

The result was one of the best hair cut and styles I have ever had.  I think it’s the whole getting out of the way of the worker so that they can do their job rather than to continually command and control them.

Be surprised by your ability to be delighted.

Do Nothing

Yesterday I visited the Forbidden City.

I spent many hours marveling at the intricacies, the excess, simplicity, harmony, feng shui, sheer number of people…  On the way out, my guide took me to a gift shop off the beaten path.  It seems like it was poised for Westerners with numerous higher-end items of jade and bronze for sale.

There was an artist there who is purportedly the great grand nephew (or some such) of the Last Emperor of China.  My entire life, I have had to live with teasings of being “gullo-ble”; which has caused me to be somewhat of an uber-skeptic about a lot of things.  Ultimately, I didn’t really care who it was or whether this person had actually painted the calligraphy I was seeing, etc.  I decided to buy one particular scroll that totally resonated with me in that particular moment.

I know full well I over-paid for it and I am fairly certain that my tour guide is in cahoots with many of the merchants for a cut.  Doesn’t matter.  What I bought was a memory, a fairly nice decoration for my home, and a ponderance that I think [sic] will be with me for quite a while.

The characters represent “wu wei” which means “no action” or “not doing”.  It was heavy.  

I immediately thought about coaching, leadership, management, etc.  Organizations seem so eager to fix everything.  ”Let’s hurry up and get to where we are going.”  or “We need to act NOW!!”  Many coaches I meet are telling clients and sorting things out for them.  Enumerating the practices and prescribing things rather than helping the client to effect their own changes or experience a shift in thinking.

In the future, I will have this scroll as an aid in training and coaching and a story that I can share with others.  Its meaning goes beyond the tangible.

And so, in the end, I received more value from the bargain than I originally surmised.


Agile At Scale? Rubbish!

I really like filet mignon.

I also really like chicken cordon bleu.  However, if you have ever been at a wedding or in a mass dining experience, you know that most of the time these dishes are best served in as small a quantity as possible.  There are other dishes that are suited for the masses.  Or, are there?

There is no such thing as “Agile at scale”.

It’s like saying “How do I scale ‘Big Picture Thinking’?” or more simply, “How do I scale thinking?”

That’s really what Agile is about, when you think about it.  Most people who want “Agile at scale” are really looking for a formula or a recipe, not thinking.  They want a prescription that will help them feel better when what they really need is a lifestyle change.  

Organizations benefit from slowing down, looking at what’s not working, what’s working, and what they should or could be doing differently.  Organizations also typically know what they should be doing differently but they can’t overcome what centuries of conditioning has ingrained in their minds.

Don’t assume that what works for one team will work for 50 or 100 or 5,000 teams.  Most importantly, don’t copy-paste!!  Instead, look for what will work with EACH team and how these things play into the overall vision and mission of the organization.  How does a small change over here affect ALL teams or ability to deliver 2-3 years from now?  

A company is a complex, adaptive system with an “intelligence” of its own.  It needs to be understood, reasoned with, etc.  Any practice that fits EVERY team across the entire company is probably harmful.  Instead, there should be guiding values and principles that encapsulate what the company cares about.

This is the spirt of Agile.  Not wholesale innovation.



We make Tumblr themes