Just one thing …

Curly: Do you know what the secret of life is? [holds up one finger] This.

Mitch: Your finger? Curly: One thing. Just one thing. You stick to that and the rest don’t mean s***.

Mitch: But, what is the “one thing?”

Curly: That’s what you have to find out.

Jack Palance and Billy Crystal  from the movie “City Slickers”

I always found this scene amusing when I was a kid. The old ranch hand trying to teach a city guy the value of focus for clarity. Of course at the time I just thought it was funny. After all these years, I realize that Curly was teaching a true agile value. Focus.

Focus is that thing that often gives us clarity. It gives us the ability to think deep thoughts and really unravel an idea. It allows us to extrapolate from a big thing into discrete pieces upon which we can undertake. It applies to things in life as much as it does in software development. I have started to really appreciate this as I prepare for an upcoming house declutter and move.

Do I allow myself to always embrace this seemingly simple approach. Nope. I, like others, allow myself to get too “focused” (and I use this term loosely here as it really not focused at all) on too many things. Like those performers that are spinning plates on a skinny stick, I find myself focusing on keeping them all spinning sometimes. But, as I am want to do, which often results in a blog post, I find myself stopping, breathing, thinking, assessing and questioning my current chartered course. So here we are.

Focus is a core value in agility as it allows us to actually be more productive by allowing ourselves to work to accomplish “that one thing” as Curly put it.

Under scrum, we demonstrate this through the user story, the task decomposition in terms of work effort. We use focus in terms of daily risk mitigation through a focus meeting called the  stand-up. We focus on the features committed within the review and the team within the retrospective. If you look closely, focus is woven throughout

Kanban has WIP and the innate concept of “pulled work” which itself a way to focus and measures this through the idea of how effective our focus on delivery is through things such as cycle time.

But there is one dimension in which I often see less focus. In the process of delivery. What I mean by this is often I see scrum development teams use a “divide and conquer” approach in which teams members use their specialized skills to scatter and seek to deliver. They are in no way being less agile in this approach but I have always wondered what would happen if they allowed themselves to focus and iterate just like the larger product. There are examples of this. Just take a look at Woody Zuill’s mob programming or pair programming as outlined in Exteme Programming by Kent Beck.

My latest read, “Joy, Inc” talks about the use of pair programming as the standard way of how they hire and how they work. They see it as not only a way to create shared knowledge by this but also to ultimately be more productive.

So, I have posed this question many times to developers and often get the same response “well, development doesn’t quite work that way” to which I often reply “are you willing to try an experiment and either fail or be wrong”? *smiles*

My logic has always been that if a sprint backlog is supposedly composed of a top to bottom prioritized list of the highest business value, wouldn’t we want to work through the items (given we identify any dependencies and work to minimize those with the product owner) and focus to deliver each story in that manner during a sprint? Or even look at the absolute most complex item and focus on completion of that story and then work on the lower hanging less dense fruit?

I see 4 potentially significant benefits that could result from this:

  1. We get items in front of our team members specialized in quality quickly so they can assess features for compliance to acceptance, note any software issues or quality enhancements and they can become productive more quickly. They are reviewing and testing completed features, even if there are mocks behind some dependent needs of other stories. They also are able to learn a portion of the system under construction and build automation against it for regression more quickly if needed.
  2. If we for some unforeseen reason we are impacted to effectively deliver on all stories for our commitment, we can at the first responsible moment, assess remaining team bandwidth, current deliverable dependencies and make decisions so that we can have that conversation immediately with our product owner so we can remain transparent on the impediment and impact but emphasize our focus on the highest priorities or largest complexity first.
  3. We reinforce iterative development at the lowest level of development (by using refactoring and integration as part of the way we work) and can focus on ensuring that we meet our agreed definitions of done at each story level.
  4. We “should” end up with a set of features tested early which should allow us to as a team to swarm baking in quality for our product and preparing for our review at sprint’s end (given we did not over commit …)

So in my view this approach makes sense to me and I have worked on teams that worked this way and we remained productive and felt like we were accomplishing more towards our product goals. We effectively delivered features regularly for review for the stakeholders.

A lot of folks may be reading this and joining the chorus of previous conversations saying “yeah, sounds good but you don’t really understand” …

So I reply to you all … “are you willing to try an experiment and either fail or be wrong”?

 

Recommended Read

“If you’re comfortable with the amount of freedom you have given your employees, you probably have not gone far enough”. – Lazlo Bock (Work Rules!)

I recently completed the audiobook of “Work Rules!” by Laszlo Bock (I went back a read passages I really wanted to dig into in the paperback as well). For those of you who are unfamiliar, Laszlo Bock is the Senior Vice President of People Operations for Google. He shares a very interesting insight into how they apply programs, policy and practices that impact employees and surprisingly how much data they collect to understand if they are actually making any real impact to the employees or the culture at large.

Some of the mystery about what/how and why Google does some of the things they do were outlined in the book. A few of them were:

  • Many of the services (like the haircut bus) provided to Googlers are at no cost to the company. It is often a brokerage between people operations and businesses for them to generate business buzz and customers. Many of things are often out of pocket for employees but adds a convenience factor for them to not have to schedule time to go and do these things.
  • The “micro kitchens” famously known at Google that allow googlers to grab a snack, a coffee, water, etc are actually spaced throughout the campus with intention to stimulate “unplanned interactions” where people from groups that might not directly work together might interact or spark and idea in one another.
  • Google has a performance management process and it gets scrutinized for effectiveness and adapted to bring the most value.

There are some really interesting ideas in this book. Not all of them are applicable to every organization but the underlying message is. If we have people focused on the operations of people and people are our greatest company investment, where is the downside?

The spirit of this book will hopefully inspire you to just think differently about how you can impact your culture in small ways and use data to determine if the “perks” you are providing are doing what you intended. I was so inspired by this book that I bought an extra copy so I could share some of this with our human resources, who are progressive thinkers as well.

I would highly recommend this book if you are leading a team, transforming an organization or maybe are part of people operations in your own company.  It will definitely inspire you to think about what things that you might be able to do to enhance the work environment and how you determine if it is working.

Stay Agile! 😀

 

 

 

 

 

 

Draw How to make Toast

Just a quick redirect to something I have stumbled across and found fascinating and wanted to share. This approach is an introduction to systems thinking and what they call “Wicked Problem Solving”. This is another approach from Tom Wujec who outlined another team approach to iterative innovation in the Marshmallow Challenge Website.

I just found this a very interesting way to get to core problems to solve for a group. Check it out:  Draw How to Make Toast Website .

Hope this gives you another tool in your agile toolbox to do great things!

Scrum Alliance Webinar

“One of the most sincere forms of respect is listening to what people have to say”

– Bryant McGill

I was very honored to be asked to conduct a webinar for the Scrum Alliance with my colleague and friend, Mr. Joe Kirk, about our agile transformation work with a state transportation department this week.

I really enjoyed discussing our journey and addressing questions for attendees.  The scrum alliance should be posting a follow-up to the talk soon in which we addressed questions for which we did not have time to do so during our talk.

Agile Transformation at Tennessee Department of Transportation

 

Using Agile Outside of Software

“There is a better way to do it. Find it.” – Thomas Edison

One of the core principles of the agile manifesto is the response to change in opposition to following a plan. That is not to say that development and following a plan is not valuable but there is a heightened value in remaining responsive to change.

I was approached this week by a colleague and friend who asked my opinion on a very structured change management framework for organizational initiatives. They have personally really grown to appreciate the idea of approaching things in an agile manner and the use of collaborative teams to find innovative solutions so the idea of this highly structured process framework seemed to raise some concern them. I thought about this a great deal and speculated that “change” could be managed just like a sprint or use of a kanban pull system just as easily.

I think that at its core, the agile manifesto (if taken out of the context of software) guides us to:

  • Value collaboration with people to solve a problem over rigid processes or elaborate tooling.
  • Produce a working value item as opposed to documentation defining what the items is to be produced so we can inspect and adapt a tangible item.
  • Remain close and communication often with customers to again help us reflect and review on progress to date and gauge possible improvement.
  • Embrace change and be open to adaptation when change occurs.

I postulated the following approach to them based on the scrum framework (these are not really new ideas, just a rehash of those before me but I find the idea of applying agile frameworks outside of software fascinating):

The Artifacts

  • A change initiative backlog consisting of specific items of change sought by the organization. This should be prioritized with highest value change initiatives first and lesser valued items much lower in the backlog. I might create these very similar to user stories with a persona who will gain value, a business value need and an expected benefit. In place of the typical acceptance criteria of a story, I might use something like expected result from change (maybe a benchmark) or maybe even some other type of indicator. Unsure there but think the key takeaway would be to split the concepts so that they could be delivered in one to two weeks but no more than a month to keep the inspect and adaptation horizon low enough to “pivot or persevere”.
  • Tasks could be decomposed by the team to address the change initiatives, again like you would with a typical backlog item and provide them an insight into progress during the change sprint.
  • In development of the initiative, I might even develop personas reflecting the target impact audience and their perceived benefits and perhaps even develop an initiative roadmap that reflected where logical “releases” of the initiative made sense.

The Rituals

  • You might perform some base forecasting to get a shared sizing indicator but I would probably forgo fibonacci and opt for t-shirt sizes, animals, etc. I would let the team determine the appropriate sizing rubric. I am really not sure that this would be necessary as you might better employ a pull system to visualize work process for something like this.
  • I would only consider keep sprint planning so that the team could make the commitment to the change owner if I were to use more of a scrum process than kanban. I think either could work effectively here although I do personally appreciate creating a sense of urgency and team buy-in with a stated commitment.
  • I would definitely keep a timebox  of 1-4 weeks to allow the team to remain focused and keep the end goals in mind. I think that this review horizon for progress with the team is essential so that they are invested and reflect the realistic amount of work that can be accomplished.
  • I would keep the concept of a stand-up and work to set the timeframe in relation to the need for risk mitigation of not meeting the commitment. I would probably stick with daily as it tends to level set people for things they have accomplished and remaining tasks to be performed. I also think that this helps reinforce the ideas of self-organization and self-management by allowing the team to reflect together on items done and undone and organize themselves accordingly. Even if using a “pull system”, I would use this opportunity to have a guided “walk of the board” so that the team could reflect on bottleneck areas, self-organize to impact them and visualize the overall flow. I would start simply with a “To Do, In Progress, Done” approach and tailor as the team learned more about its general workflow states possibly.
  • As I stated earlier, I would define a timebox for progress demonstration of the initiative items and team reflection like the scrum framework review and retrospective.

The Roles

  • A “change owner” (just like a product owner) represents a group of stakeholders for the organization and is the single voice to the team when it becomes stuck, needs clarification or needs an immediate decision. This person would need to be empowered by the business to own this change effort as they will have the ability to provide iterative feedback to adjust course accordingly at the review.
  • A cross-functional team. One of my favorite design firms is known for this idea. In applying this to the concept of of an organizational change initiative, I believe that you would need to ask yourself some clarifying questions:
    • Is it more important that I have all the skills necessary for the delivery of a change item?
    • Is it more important that I get a good cross section of my organization of all types of roles that are critical thinkers and “doers”so that I can get a better reflection of the organization as a whole and to provide broader context?
  • I would also use the concept of a scrum master type role to help keep the team focused and productive. I might tag them more as a team coach focused on helping them through the process, teach them heightened skills to work as a team, assisting with impediment removal and assisting them to reflect on the process for continual improvement of the team.

I think the key components to making this work in a non-software situation is to still be value and customer focused and treat the initiative like a product so that it could be developed.

Folks who typically read my blog may be saying to themselves “yeah, this just makes sense” but for people outside the world of software, sometimes the concepts of iterative building seem foreign and they see things in “final state”. This is just an idea for them to see how they might apply this to their domains of business. I do think that providing the team the concept of focused effort would make this more productive but in the context of business domains this might be difficult. Capacity management strategies, micro teams or just allowing them to suspend their daily effort and focus for a timebox (by having others manage the daily activities) could be an option. I do think using a pull system might allow for an interrupt driven process but I also would be concerned that most might have difficulty determining true criticality of work they typically are expected to perform today. Being an agile leader and allowing this focus may draw some criticism but you might treat it like an experiment, run a few sprints with focused effort, reflect on the work accomplished and adjust as needed.

One thing that I told my bosses when I pitched my first scrum pilot to help secure buy-in was “you will review progress every 2 weeks. At this time, you can choose to continue, adjust or stop funding the project altogether and abandon the effort. Failure should be an option but the goal should be to fail as fast as possible if we do so.”

We are already seeing this done a great deal in many industries, automotive, design, marketing, education and even in areas such as program development at NPR. So this is definitely not a new phenomena but it is interesting to take a step back away from the world of software and ask ourselves how might we harness what we know already about agile principles and processes and apply them in a unique way to build something other than software. It fascinates me. So take a moment, is there somewhere that you see complexity in an effort that would benefit from an empirical approach. Maybe you should be a catalyst to help someone try something new.

I leave you with this quote that I have always appreciated …

“Success isn’t about what you accomplish in your life. It’s about what you inspire others to do” – Unknown

 

 

 

 

People Operations

“You don’t build a business, you build people. And then people build the business”.

Zig Ziglar

I have just finished the book (and looking at diving back into some passages to read again)  “Work Rules” by Lazlo Bock, head of people operations at Google. The reason I began reading this book has been a strong belief of mine that the hiring, supporting, growing and retention of people is a core skill that an agile organization needs. I began really turning this idea over in my head more and more as I read several books that emphasized people over product. And as I have been slowly rebuilding an organization, it has reinforced how important really understanding how critical a focus on the marketing, hiring, onboarding, growth and retention really are. It’s the lifeblood of what you probably do.]

Let’s be honest. Products have a shelf-life (anyone remember Friendster?) that is measured in brief flashes of time.But for an organization to create longevity, people make this happen. This is an organization’s largest investment. This is what allows you to continue to innovate and grow.

So isn’t this just “Human Resources”?

I consider the idea of people operations much more than standard enterprise human approach towards management of hiring and employee policies, employee benefits, etc.

I like to think of this idea as “HR on steroids”. A group whose focus transcends above the idea of management of employees and related items to one that is focused on how we market our jobs, create and celebrate culture, how we hire, onboard, grow, retain and appreciate and reward our people. It’s that next level which begins to consider even more than hiring/firing/benefits and paperwork to one that creates and measures programs that enhance the employee experience and organizational culture to strive to create a place that people seek to be a part and see the personal investment in them when they join.

For us to evolve and change, continue to attract the right people making cultural contributions as we grow and providing them with the employee experience, the nurturing and the vision of being part of something more than a job, people operations is what helps us make this happen today and pivot as we change and grow. A focus on the individual and the group, their work experience, their growth, their concerns, their restlessness and the culture by a group that’s primary mission is to continuously improve. That’s a pretty powerful concept to me.  Someone who works in an agile manner, performs experiments to help better the work experience for its people (and is unafraid to fail), uses data to help understand how needs within the culture are changing, keeps up on trends to enhance the workplace and has the ability to broker ideas for the enhancement of the employee experience. They spend their time not only supporting the people they have today but looking at ways to grow leaders from within, enhance the company culture and cultivate a shared vision for the work community and find ways to reinforce the values upon which you are built (in effect helping an organization “walk the walk”).

So what are some things I can do to move in this direction?

  1. Make friends. If you have a current human resources group, build a partnership. Understand and respect what they do. Understand their constraints and guidelines that they may be bound to uphold. Don’t throw stones at what you do not understand. This partnership can allow you to possibly create a local extension to your own group that understands the processes, the players and the scope of what they have to get done as well.
  2. STOP REFERRING TO PEOPLE AS RESOURCES! Again, my particular pet peeve but I hear this more from organizations that are working directly with the people being referenced (“Say, Bob; do you think we have enough resources on the team for us to get our scrum on”?). I understand that this is a conditioned thing that many (including myself and I have to police my own speech) of us learned from years of experience with software projects or operational context. This is not mandatory, but asking “do we have the right people in the right seats” rings a more sincere question than “do we have the right resources in positions”.
  3. Just do it. (Take a tip from Nike). Start starting. Determine if you can make this kind of commitment. Maybe you can, maybe you cannot. Maybe you are unable to create dedicated focus of a person or group to this. Leverage passionate people you have through “tribes” and find ways and incentives to provide them the time and tools to help create a focus on the people you have today and the people you will be fortunate to have a shared experience with in the future.
  4. Reflect. Determine ways in which you can collect information/suggestions/ideas  from employees and use this information to see how you can add value, enhance your culture and improve the overall work experience. Try things. Do amazing things. Fail at things. As long as your goal is to create a focus on the people to enhance the company culture, the employee experience and create value that will assist in the caring for, growth and support of the people who work for the organization, I think everything will be fine. Use data to allow yourself to examine programs and phase them out, change them, enhance them or drop them over time as needed.Don’t implement ideas blindly and in a vacuum. Measure them in a manner that will allow you to determine if they are beneficial. Test waters by doing pilots as opposed to “turning the ship at once”.

Again, I have just been deeply inspired through introduction to several ideas, stories and concepts to determine how I can make a deeper investment in people operations which in turn, I feel, is a deeper investment in the organization. These ideas are not anything new. Google, Ideo, Hubspot, Menlo Park, Zappos all maintain a core focus group for their people. They know that the culture they create within their organization allows them to evaluate potential employees, hire the right people to be value add to their organization and create something bigger than a job to paycheck ratio as why they continue to work for a given organization. I am personally ready to selflessly invest in the people I work with today and the people that will enhance the culture in the future. Are you ready?

A friend of mine (who knows how passionate I am about growing a new work environment in my industry) sent me the follow adage which seemed to fit the ideas behind this post.

CFO says to  CEO:  “What if we invest in our people and they leave”?

CEO replies to CFO: “What if we don’t invest in them and they stay”?

 

First Responsible Moment

You cannot escape the responsibility of tomorrow by evading it today. – Abraham Lincoln

Responsible is defined as “being the primary cause of something and so able to be blamed or credited for it.” While this sounds very straight-forward, I think sometimes in growing in our agility as a team, a leader or an individual we can forget the power of this word.

Responsibility is a cornerstone to agile thought in my opinion. We strive to teach our teams to be self-managing and instill the idea at the lowest possible level by having them select the work and manage its delivery. As agile leaders, we embrace responsibility coupled with our willingness to experiment, learn and grow and as a basis to keep at bay the fears of failure.

There are three core concepts that I try to instill and reinforce in teams; I ask that they apply a litmus test of reasonableness and responsibility to decisions they make (on an individual, team and organizational scale) and that they respect the power of the “first responsible moment”.

Being Reasonable and Responsible

What does this really mean? It sounds powerful, but also sounds very idealistic. For me, it is very pragmatic. I use these values for myself and my teams as a base “sanity check” for decision making.

Approaching decisions from a position of being reasonable and responsible breaks down this way for me personally allowing me to examine the decision to be made by asking questions:

  • Is what I am proposing an idea or solution that brings value not just to myself but to my team as a whole and the organization?
  • Is this a hotfix solution or does it hold long term value?
  • Am I proposing something from a position of fear or merely pain avoidance?
  • Is what is being considered the right thing for us to be doing?
  • Do I actually believe in this idea in that I could passionately communicate and adapt this position if necessary?

This seems like a lot of “stuff” to go through for a decision but it is really quite simple as when people have a shared understanding of “being reasonable” it really takes little time as muscle memory forms to evaluate quickly (reinforced by a solution oriented outlook).

But here is where the kicker comes in. Evaluation as to the reasonableness is half of the picture for an agile mindset. The final question is the linchpin of this approach.

“Are we willing to be personally and team responsible for the outcome of the decision we are making”?

This takes this application of values to a whole different level. This means should things go sideways, are we willing to accept the consequences of our decision and adapt to self-correct? Are we willing to accept that we failed? Are we willing to re-evaluate our position?

Coupling this with the personal willingness to accept the end result of the action is part of the core definition for this idea.

So why “first responsible moment”?

Again, in my humble opinion, this idea is a cornerstone of agile thinking and doing. It helps support our lack of fear to fail and reinforce our open communication. It empowers us to be transparent and promotes healthy working relationships that reinforce trust among people. It is something that I say often to teams when they encounter a problem.

The “first responsible moment” is how we approach obstacles, problems and impacts. We open the channels of communications to those invested into our work as soon as we see a problem that may impact our commitments.

Often times, there is a lot of fear that surrounds the need to have a conversation that delivery may be less than forecasted. But if we are truly building a healthy agile culture, we use this concept to allow fear to be diminished by encouraging folks to communicate an obstacle or impact as soon as it becomes visible and disruptive.

This does not always necessarily mean the inability to overcome and deliver but what it does do is to set the expectations of everyone involved in a reasonable manner. It always opens a communication for examination to see if there is partial value that may be salvaged and it strengthens the relationships through candid visibility into work. It allows us to take a problem at first encounter and approach it as a discussion for solution.

In an agile (or probably any other) world, no one likes to fail. My teams wring their hands and sometimes beat themselves up too much so I ask them to reflect in retros on “what happened” to create this situation. Sometimes by doing that, we can see patterns of actions that set us up to get there. If we can find these, then we can take actionable steps to reduce the likelihood of failure under those exact sets of conditions. But what is more important (as you noticed I inferred that you cannot just generalize failure to certain things) is that we learn more about ourselves, our team and reinforce our embrace of change. Sometimes things like sickness of a team member can cause items to become in jeopardy.

It can often be random events that create an obstacle. We cannot control the unknown, but we can control our response to it. One of the worst things we can do as a team is to remain silent, kill ourselves to meet commitments for which we know may be unachievable and damage our relationships by waiting until the last moment to make people aware. This stands potential to damage us as team and an organization. We may get the commitment out, but what did we lose as a result? I am not naive to realize that there are times when we are so committed to our work we go “above and beyond” to deliver. But this should be the exception and not the rule. A sustainable pace is always a better approach coupled with the “first responsible moment” when impacts arise.

If you, or your teams, are not presently practicing this concept, give it a try. I think you will be pleasantly surprised at how it can tighten the relationships and reinforce the core values of agility.