Aesop’s Advice on Pleasing Everyone

I came across this fable from Aesop (6th century B.C. ) and wanted to share it …

A man and his son were once going with their Donkey to market. As they were walking along by its side a countryman passed them and said: “You fools, what is a Donkey for but to ride upon?”

So the Man put the Boy on the Donkey and they went on their way. But soon they passed a group of men, one of whom said: “See that lazy youngster, he lets his father walk while he rides.”

So the Man ordered his Boy to get off, and got on himself. But they hadn’t gone far when they passed two women, one of whom said to the other: “Shame on that lazy lout to let his poor little son trudge along.”

Well, the Man didn’t know what to do, but at last he took his Boy up before him on the Donkey. By this time they had come to the town, and the passers-by began to jeer and point at them. The Man stopped and asked what they were scoffing at. The men said: “Aren’t you ashamed of yourself for overloading that poor Donkey of yours—you and your hulking son?”

The Man and Boy got off and tried to think what to do. They thought and they thought, till at last they cut down a pole, tied the Donkey’s feet to it, and raised the pole and the Donkey to their shoulders. They went along amid the laughter of all who met them till they came to Market Bridge, when the Donkey, getting one of his feet loose, kicked out and caused the Boy to drop his end of the pole. In the struggle the Donkey fell over the bridge, and his fore-feet being tied together he was drowned.

“That will teach you,” said an old man who had followed them:
“PLEASE ALL, AND YOU WILL PLEASE NONE.”

And even worse, “you might lose your ass in the process” … 

Advertisements

Inspect and Adapt

“You’ve got to be willing to lose everything to gain yourself” – Iyanla Vanzant

The title of this post states two key elements of the agile approach. But this post is not application of these principles to software, it’s application of these principles to yourself.

I have been spending a fair amount of my personal time in reflection. Thinking about where I am, the skills I carry and have been successful in my career, the things I enjoy doing (or do well) and the things I don’t do as well. My fears, my life/work balance, the whole “kit and kaboodle”.

The reason I have been doing this lately is I have been taking a keen and unbiased look at where I am at right now, what I have helped build and thinking about what it takes to get it to the next level. As unsettling as it is to personally discover this, I don’t know if I have the skills to be the “feet to the ground” to achieve this next rung of success. I feel that I am at a point to either adapt or “get out of the way” to get to that next level.

I have focused a lot on encouragement of self-management and self-organization and structuring teams so that commitment and outcomes matter so that they can be empowered to have open conversations about real potential delivery and meet those commitments. I have protected and defended teams to the best of my ability to support their ability to focus and deliver, which on the average they do successfully over and over again. I started with an idea of how software should not be built under overly prescriptive processes and the value of showing “early and often” to stakeholders would support a value-driven approach that would not leave stakeholders unsatisfied, teams demoralized and dreams unrealized. I had a drive to bring the ideas of value-driven software development to the public sector and show that it could be a successful way to approach delivering software. I made commitments to leadership to make them successful by driving the idea by hiring the right people and building the right organization under which this could happen. I met these commitments and integrated the idea (with a lot of great people) into something never seen before in the public sector in my arena.

What I have learned through thinking through all of this is that I did just like a founder would do in a startup. Through sheer will, vision and drive; I assumed any role necessary to build what was in my head and make it work. The small group of believers gathered people along the way that help keep moving and we stood up something amazing. Yep, we did this and I am really proud of what we have done here. But as proud as I am, I have made a startling revelation for myself, I live in the world of ideas and unrealized possibilities not the world of day to day business operations.

The Visionary and the Integrator

One thing that I have recently learned from a couple of books I have read recently (“Get a Grip” (Wickman and Patton and “Rocket Fuel“(Wickman and Winters). The first book outlines what Patton calls the EOS (Entrepreneur Operating System) process and the latter is a deeper examination into (2) key roles in business that they identify; the visionary and the integrator.

The Visionary

This role in a business is typically a founder. Described as the person that has “20 ideas before breakfast” and someone who often has difficulty with the detailed level. Basically a “big picture” person who carries a vision and is looking externally to the company for charting the future. This person can potentially whiplash the business if leading the ship.

The Integrator

This role is the engine that gets things done in the business. This person keep the “trains running on time” and assumes the realist point of view that is focused on getting things done. This role is adept at taking the vision and direction and making it into a business plan that can be executed. They are the balancing part of this relationship with the visionary to filter all of those ideas streaming out to help the visionary focus on refinement of the gems that they can create a plan of action around and drive the organization.

Through a lot of personal discovery for myself, I have realized that I tend to have more of the traits of a visionary than an integrator. I like to live in the world of ideas and unrealized possibilities of an organization and what they “can be” but have little stamina to see them created into actionable items that and can become easily bored when dropped into the minutia of details. As painful as it was for me to personally realize this for myself (as I am in a role now that has me doing both roles), I like, and am successful, at building things, but I do not like, and am less successful, at running things.

I think I never realized before I read these descriptions that I was in that startup mode mentality where I needed to play both the visionary and the integrator roles for the part of the organization that was being built on the onset.

Although, I am able to “do” both roles, I do not “enjoy” both roles (therefore making me inefficient at the needs of the integrator role). I have just recently realized that the only way for me to continue to bring the highest value to this organization in moving to the next level is to find that key integrator role (or roles) or move out of the way for someone to take it a new direction to continue to add value and find the next passionate thing for me to build that holds the highest value for an organization and the highest personal satisfaction for me in doing what I love.

It’s a very scary and liberating at the same time to have some realization of what a core strength is for you might be and then figuring out how you use it. I truly believe that gaining these types of insight help me figure out how I can do the absolute best for the people I work with. It also helps me realize that I never stop discovering who I am and what I have to offer. I merely refine it.

In light of what things I am learning about myself, I leave this post with a quote from Albert Einstein:

“Try not to become a man of success but a man of value”

The Value of Being Focused

” The sun provides the earth with billions of kilowatts of energy, yet if you stand in it for an hour, the worst you will get is a little sunburn. On the other hand, a few watts of energy focused in one direction is all a laser beam needs to cut through diamonds.”                                – Traction by Gino Wickman (paraphrasing Al Ries from the book Focus)

I am presently reading Traction by Gino Wickman and came across this quote and it struck me a very good analogy of the power of truly being focused. Just as the earth’s atmosphere takes billions of kilowatts of energy and diffuses them so they do not scorch the planet, a laser, in contrast, takes a fraction of this kilowatt power of the sun and through focused energy emits amazing power.

Extrapolating this analogy to a business approach, trying to accomplish everything at once in a large scope of intensity it is likely that you diffuse the overall effort or impact (like the atmosphere for the sun) to a minimum. However, if you focus your efforts, like that of a laser then you stand the opportunity to create a massive amount of powerful impact overall.

So, I ask myself (and ask you to ask yourself), are you approaching what you do like the sun? Are you expending vast amounts of energy in such a wide spectrum that you are diffusing your impact? Or are you focusing your energy, like a laser beam, and in turn taking a smaller capacity of focus and making it impactful?

For myself, I often feel like the sun but earnestly work hard to become a laser …

 

Our Sprint Cycle

I was asked by a colleague how we have designed our software sprint cycle. As I explained it, I thought that this might be a good topic to just outline as part of this blog. This approach, which could be dubbed “lucky 13”, is the standard of how we conduct product work. Is it perfect, probably not, however, we do see it as an experiment and evaluate its effectiveness over time.

Some precursory notions as to why we built our sprint cycle this way:

  1. We want to be reasonable and responsible in how we build software and give a predictable horizon for commitment delivery to the product owners.
  2. We want to give the proper space for planning, tasking, review and retrospective
  3. Continuous learning is highly important to me and our organization so it was with intention that we built in slack time to allow us to do this.

So how does it work?

Day 1: Planning and Tasking the Work Ahead

This is our planning and tasking day. We split it into portions to allow the conversations to occur so that we can gain understanding and make our commitments as well as use the second half of the day to decompose the work ahead.

Days 2-11: Product Build/Test/Deploy

Composed of 10 working days for building, testing and deploying our code to meet the commitment and prepare to review for the product owner. 15 minute daily standups are held throughout this cycle to synchronize the team work.

Day 12: Review and Retrospective

Typically our product review occurs in the morning allowing us to demonstrate the features for the product owner. We will, on occasion, have a window for sizing any new stories that have emerged into the product backlog. Following lunch (usually as a team) the team meets in the afternoon to conduct their retrospective. While many of our retrospectives focus on improvement in the next cycle, we often times balance this with focus on team unity, team health and technical discussion as needed and to keep the retrospectives fresh and engaging.

Day 13: Lab Day

This is the slack that we build into our schedule for continuous improvement. It’s a very small horizon so deep work is unlikely to occur. Teams spend this time learning new skills through online training, have more “deep dive” technical discussions or discuss refactoring that may be needed as a result of accrued debt within the cycle. This point in the horizon accomplishes two important things. 1) It allows teams a moment to reflect on their skills, their product and seek to learn as a part of the culture. 2) It gives the team a momentary “breath” between sprint cycles. It allows them to level set, focus and be prepared for the next sprint

How we Adjust Capacity

We made a conscious effort to really consider team impacts and after observation we determined that our team impacts to capacity occur in two major forms; team capacity loss and team member capacity loss. We handle each of these differently.

Team Capacity Loss

If the entire team is impacted, by a conference, a holiday or an “act of God” disaster, we consciously adjust our schedule to account for this impact to allow the team to retain a full 10 day build cycle. This does not happen very often but we found that it is best for us as it retains consistency within our development cycle.

Team Member Capacity Loss

This is handled differently based upon the reason behind the impact. If a team member has a planned outage (vacation, doctor’s appointments, etc) then we adjust the capacity for the individual based on the outage and the team adjusts their commitment accordingly to compensate for this team member being out. They communicate about this prior to the next planning meeting so they can make this impact visible to the product owner.

If the team member has an unexpected capacity reduction such as sickness or other life trauma; the team uses the idea of “first responsible moment” to make this impact visible and communicate impact to the commitment to the product owner. It has become generally accepted in our organizational culture that in doing this, they provide insight as soon as they are aware of impact which builds trust and openness between the teams and product owners. It also provides the product owner an opportunity in the face of impact to have a conversation with the team to determine if any value can be salvaged from the commitment impact and provides them insight early to review release plans and manage stakeholders.

Pros and Cons of this Cycle

PROS:

  • It provides a given horizon for the teams and the product owners.
  • It allows the teams to control and adjust the work based on impact. It reinforces the agile values of self-organization, self-management as well as transparency.
  • It gives team space to ask questions before beginning a sprint cycle in a larger context before commitment to create shared understanding or if necessary split stories, etc.
  • Through building in slack time within the standard sprint cycle, we foster the value of learning and provide the space to do this on a regular basis.It also allows for team building and to “level set” for the next sprint.
  • For our organization, this sprint cycle appears to be a “sweet spot” of predictability and maintaining a small enough horizon to effectively manage risk.

CONS: 

  • Using such a long cycle only allows roughly two sprint cycles per month.
  • The horizon of the “lab day” is very small in scope and therefore no in-depth learning can occur.
  • I have been challenged by purists that this is not a typical scrum sprint cycle as I have purposefully pushed the beginning and ending “rituals” outside of what people think the sprint should be. What we discovered was that the teams sought more time to prepare for the work and therefore made a conscious effort to give them this space. We also felt that the review and retrospective should have its own horizon for effectiveness. I do think we are following the base scrum guidance of a sprint being 1-4 weeks and performing the rituals prescribed. We just feel that they needed more focus outside of delivery to heighten effectiveness.
  • This cycle relies a lot on emergent design from both an architectural and product design sense. Finding ways to place this better into the context of product planning so the team could have wireframes and user experience for guidance (and refine during the sprint) as well as base architectural guidance would be helpful. We are presently evaluating how to best facilitate this.

So, this is how we build products at my company and what has worked for us. This may not be the end result of where we land but we’ve been using this approach effectively over the past 2-3 years. As most everything we do, we see this as an experiment, open for refactoring, destruction or re-envisioning. The process doesn’t make us special, it’s the people and the fact that we know that the process just helps keep us on the rails.