During my final year in High School, I took a programming course in which I learned/relearned QBasic and Visual Basic. Both languages introduced me to numerous elements of programming. While I learned a lot of elements, I would learn some underlying principles later. For instance, my final project was a turn based role playing game. To turn the code in, the teacher asked that we print out the program. At 80 pages, my project was by far the largest. I was not blessed with super-speed typing, but I did possess the ability to copy/paste the common elements where ever I needed them.

In these early years, I had not learned the DRY Principle. There are many elements of good software that developers learn throughout their career. One that quickly becomes ingrained is the DRY principle, which is an acronymn for “Don’t Repeat Yourself”.

DRY reminds developers that the best, easiest code to maintain is the code you write once, and not the code that you write or copy/paste repeatedly. It challenges developers to reuse code and castises them for when they copy and paste code.

This principle works well with code, but it doesn’t hold up when working with people. Try as we might, we can’t just tell someone something just once. It often takes several times for a message to be heard, understood, and engrained. Old marketing guidelines state that a person needs to see or hear your content 7 times before a consumer truly hears the message. Those that we serve also need to hear a message several times. A new process, a new business direction, a new vision, stated only once, will never come to fruition. It takes frequent reminders, frequent statements, for anything a leader shares to be heard by all.

Leaders have to operate by different principles than Engineers. Instead of DRY, think of RYE - Repeat Yourself Everyday. Only through repitition of the same message over and over can a leader ensure that a message is heard.

Very shortly, my old blog site, kevin.generalizingspecialists.com will be shut down. A lot of my older posts here, like The Coach part of Agile Coaching was taken from this site. A colleague and I had envisioned launching an agile podcast 3 years ago, recorded one episode, and concluded we did not have the time to pursue the project further. The most fun from project has been bringing it up in conversations around the concept of Generalizing Specialists.

The concept of Generalizing Specialists is near and dear to the heart of a Jack of All Trades like myself. I’ve held every role on a typical Scrum team, I’ve spent 6 months on a DevOps team, and am currently a Release Train Engineer. From this eclectic background, I have numerous skills that I bring with me. A Jack of All Trades like me is the ultimate Generalist, capable of filling any role, wherever the need arises. It’s characterized by the ability to plug in the gaps, when they are found, and ensuring things continue to move forward.

Jack of All Trades get a bad rap though, as they are often derided as being Masters of None. Some argue that they are over generalized to the point that they have no single area of mastery.

In discussing the concept of Generalizing Specialists, the ancillary concept of ‘T’ shaped skills is often mentioned. The idea is that a capitalized ‘T’ represents one’s skill level in a number of skills. It’s not very deep in ost skills, save for one in the middle. A Jack of All Trades, on the other hand, would have a ‘-‘ hyphen shaped skills. The hyphen may be wider than the ‘T’ shaped skills of another, but there is no one area of mastery.

Except, I think there is one area of mastery that Jack of All Trades are masters in - playing in the white space between roles ang groups. By being adept and filling any role, these individuals have learned how to maximize their ability by recongnizing gaps and doing what it takes to get the job done. Those that get a thrill from doing anything and everything will find a way to discover where they are needed and make themselves useful.

In startups and small companies, you see many Jack of All Trades out of necessity - without a large group of people, the need hasn’t risen for granular role specialization. For the business to keep operating, everyone must fill in the gaps wherevery they may be.

Large organizations, with the economies of scale that they operate at, seek out specialists. Look at most job descriptions, especially for those for a developer in a large organization, and you will see very specific languages and tools referenced, as the organization has setup specific roles. But a large organization needs Jack of All Trades too, to play in the white spaces between their specialists. In a software organization, these Jack of All Trades are often the leaders, the managers, Scrum Masters, and Release Train Engineers, who are all adept at identifying those gaps and calling attention to them. The way these gaps get filled will vary from person to person and role to role. But identifying these gaps and where teams are impeded is the speciality of agilists at any level.

The term Jack of All Trades was preceded by a British term, Johnny-do-it-al. It also had a bit of a negative connotation when it was introduced to describe Actor, Playright, Poet, and Businessman William Shakespeare. Just because you do it all doesn’t mean you can’t be wildly successful.

Like any kid who grew up in rural Ohio any time in the last 50 years, I played little league baseball. I never had a knack for it. I played in the outfield often and could not throw far. So, when I fielded the ball, I would run the ball in from deep in the grass until I reached the sand and only then throw it to my teammates, as if I could outrun the base runners. Looking back, I’m amazed anyone put up with me playing on the team, since I clearly couldn’t field and had little success in the batter’s box either.

Our coach worked with us on two things: the fundamentals of baseball, such as hitting, catching, fielding, and throwing, and good sportsmanship.

As the saying goes, “it’s not whether you win or lose, it’s how you play the game”. That was a good mentality to take with me on the team.

As agile coaches, this mentality applies doubly to us. We have many eyes on us. We set the example for how teams should cooperate, collaborate, and function together. It matters less if we are successful or “right”, as long as we deomnstrate the value and behaviors that we coach our teams on. We are all human and we will make mistakes. Our mistakes should be the exception, and not the rule. We should strive to habitually embody that which we stand for.

Returning to our sports analogy, what kind of sportsmanship would you expect to see from a team that is coached by someone who yelled at every mistake, threw their hat when the other team scored, who argued with the umpire when they disagreed with a call, or berated the team when they lost? These players might become decent ball players, but would they be people you would want on your team? (No thanks, I’ll pass.)

Are the actions and behaviors you have at odds with the Agile values and principles? If so, consider where your team currently struggles with in Agile. As the team is in some way a reflection of you, they will likely struggle in the same area as you, because you have not shown them how to be successful with it yet.

While not every player or team member we coach will become a star, they still need to operate well within the team. But, they may one day become a coach in their own right. And if you demonstrated the right values for them, they’ll likely carry it forward for the next generation, teaching others the right way to play the game.

I love finding great coaching lessons in unexpected places. A few years ago, I watched a comedy special by Craig Ferguson where he posed these 3 questions one should ask others before speaking.

Does this need to be said?

As a coach, not everything we think of needs to be addressed. Perhaps the team didn’t discuss a story during the standup. Given the current development of the team, the day of the sprint, and the importance, consider if the omission is important enough to call out.

Does this need to be said by me?

A coach doesn’t have to be the one to point out an omission or problem. The best agile coaches are teaching there team to work together, and this includes holding each other to high standards and ensuring everything gets done.

If a team is far enough along in their growth, it may be detrimental for the coach to call out very basic advice or poiut out obvious problems. But, if the coach waits long enough, someone else may speak up. My best coaching moments have come from when others are applying the lessons I’ve taught them and calling out the problems I’ve taught them to look for.

Does this need to be said by me now?

The final question ponders the timing of coaching intervention. Is now the right time to act? Or, would it be better to save the conversation for another time, such as the sprint retrospective?

Conclusion

Coaching is based on soft skills, which can be learned from anywhere. Keep your eyes and ears open, and you may find some great tips from the unlikeliest of sources.

A common problem I see time and again across development teams, organizations, and industries is difficulty with the Product Owner role or Product Management in general. How is it that team’s struggle in this area so often? Why can we find quality Scrum Masters, Software Engineers, and QA Engineers easily, yet the great product person is as rare as a Straight Flush in a hand of poker?

One can look to the books we have to teach the various roles. Amazon returns over 60,000 results on both Computer Programming and Quality Assurance, yet only around 4,000 books on Product Ownership. While not exactly a scientific method, it is indicitive of the market supply and demand for such topics.

But let’s take this a step further. Software Engineers, when they have a college degree, often have a degree in Computer Science, Mathematics, Software Engineering, or Informatics. Yet what degrees exist in traditional universities for Product Management? Carnegie Melon, University of Wisconsin, and New York University all offer a Masters in Product Management from their business school, but there does not appear to be any bachelor degrees for Product Management. This leads to a disparity in skills. While Software Engineers often have years of training before joining a team to write code, many Product Owners learn on the job, being mentored by those who have cleared a small path before them.

There are certifications available, like those for a Scrum Master, such as the Certified Product Owner, that provides a general introduction to product ownership, including writing stories, prioritize a backlog, and how to plan a sprint with a Scrum team. There are also training courses like Pragmatic Marketing, which provide more advanced training and a framework around discovering needs, crafting a plan, executing, and releasing a product.

And while these trainings can help a Product Owner get up to speed on their role, the simple matter is that the Product role requires heavy reliance of soft skills and influence. Technical skills, such as the steps needed to write an automated test, are simpler to learn in comparision. While one is crafting an automated test, they can refer to notes on the subject until they have mastered the steps, yet a Product Owner might get a sideways glance if they bring notes to a backlog refinement session, a meeting with a stake holder, or a sprint planning.

Your traditional training tries to assuage this by going through “simulations” in order to give Product Owners a feel for the job. And this is a good approach, but it is just once, must be done in a group, and the pace of most clasees allows little time for reflection.

But dedicated practice and exercises are a great way to build product skills and confidence. The first challenge is finding time to practice. I personally find Friday afternoons at the quietest time of the week. A couple hours after lunch are a good time to set aside to learn and practice.

The second dificulty then is how do you practice product ownership? Hear are a few exercises you can try to practice writing stories, defining acceptance criteria, and prioritizing a backlog. There’s more to product ownership than this, but this provides a good foundation for the rest of the skills.

Product Ownership Exercise

First, identify a software product or feature you use everyday, such as the latest Facebook feature, a “Pizza Tracker” for a pizza shop, or your Out-of-Office feature of an electronic calendar.

• what is your vision of what this product or feature will be?
• What stories do you need to implement this product or feature?
• What would you name the feature?
• What description for hte user stories?
• What acceptance criteria would you identify?
• Finally, what order would you want to implement these stories so that you can maximize value delivered?

For the purposes of this exercise, ignore any technical implementation details, technical dependencies, and ignore any technical concerns in terms of priority order. It’s the responsibility of the development team to serfuace these, which you would normally uncover when refining, estimating, and/or planning these stories with the team.

As a bonus exercise, find a peer, each choose the same product and feature, and independently build your product backlogs. When complete, compare your backlogs and discuss how you each choose to write the stories and prioritize them. What simularities did you have? What vision did you have when creating your backlog, and how do your product visions differ and did these differences lead you to different backlogs?

We’ve all found ourselves part of great teams that just ‘click’. These teams are capable of achieving great things. These teams are the teams, years later, you look back and are proud to have been a part of the team and amazed at what was accomplished.

On the other side, there are teams that are a bear to be a part of. THings are just off, and no amount of team building, norm setting, or retrospectives fixes the issue. What gives?

Whether you are in school, sports, work, or in my case, agile software development, teams are an integral part of working, learning, or having fun. But how can we get team formation wrong? What inhibits a team to form?

Patrick Lencioni in his fable 5 Dysfunctions of a Team, lays out a pyramid of dysfunctions that inhibit team formation: Lack of Trust, Fear of Conflict, Lack of Committment, Avoidance of Accountability, and Inattention to Results. Each one builds upon a previous one. I see these as a progression, or a journey in the evolution of a team.

While all of these are critical to a well-functioning team according to Lencioni, Lack of Trust and fear of Conflict will inhibit a team from forming the most. If a team does not trust eachother, they will act as individuals in their own self-interests. Further, if a team is afraid of conflict, they will not challenge each other and you have a team with false harmony - brushing aside their problems just so it seems like they all get along.

In another fable, Patrick Lencioni tells us of the Ideal Team Player, someone who is Humble, Hungry, and Smart. Humble is somewhat self-explanatory. Hungry means a team player will put in extra effort to achieve the group’s goals. Smart refers to Emotional Intelligence, meaning an ideal team player knows how to work well with others. If you have team members who lack these skills, team formation will also struggle.

Personality differences can also inhibit a team from forming. While I’d like to think that anyone can work well with anyone else, in reality, there are some people and personalities that just struggle to get along. SOmetimes, this is seen as polar opposites, someone driven by competition and someone who abhors competition. But sometimes, it’s a combinition of personality traits that cause individuals to struggle on a team together. This is when leaders can step in and re-arrange teams to find an ideal mix of personalities, background, and diversity in an aim to find a better functioning team.

But sometimes, the problem lies with the leaders themselves. If a leader establishes goals that are counter-productive to team formation, such as individualistic goals, or worse, goals that pit team mates against each other, how can a team form in these conditions?

Beyond the leader, the culture must also support and celebrate the team and not the individual. When teams are celebrated and recognized, it makes it clear to individuals that they cannot succeed without their team around them. When team members are given team-driven performance goals and not individual-driven performance goals, it is clear that an individual must work with their team and help it do better in order to personally do better.

There are many ways in which team formation can be stunted, slowed, or prevented. To ensure teams form, hire for people who are humble, hungry, and smart. Establish team level goals and rewards. Consider personality types and seek to find good matches where possible. And finally, ensure leaders walk the walk as well as talk the talk.

I set out in 2018 to read more than I had in previous years. For me, my biggest hobby is learning, and books are the most prevalent avenue to learning. While I do enjoy reading for entertainment, there was something I learned from every book I read in 2018. My goal was to read 2 books a month, or 24 books in total. In the end, the list tallied 27 books! In 2019, my goal is to average 2 1/2 books a month or 30 books overall.

The 12 Week Year

The basic premise in this book is that we often get more accomplished at the end of a year when we are most focussed on our goals. But, in the span of a year, we might lose sight on our goals and waste value time. So, this book argues we should treate every 12 weeks as a year, and plan 2 or 3 goals, with laser focussed actions or tactics to achieve the goals, with a focus of having measurable goals.

At work as a Release Train Engineer, I am used to thinking in about quarter long cycles for our planning and execution processes. I’ve adapted this process for me, using it along side my main organization system I’ve been using for a year and a half now…

Getting Things Done

This was actually my 2nd reading of this book, having first read and adobted this process a year and a half ago. The 2nd reading helped me realize even more the importance of capturing actions and thoughts, but also clarifying them enough so that my mind no longer has to think about it. And if it does, then I need to do more thinking. There’s a lot of productivity gems in this book, many of which have been distilled else where at this point, but the overall process explained here can be VERY heavy to implement. But, I know have all of my next steps captured, I follow up on the items better, I know the trade-offs I am making, I have thoughts captured for later contemplation, and, thanks to using an electronic tool Facile Things, I have metrics on how much I’m getting done and where I am spending my time.

Setting the Table

I picked this book up after the GLS 2018. This book reads more like a memoir than a business book, but I found a number of interesting tidbits that could apply to coaching and being a servant leader. Especially interesting was the concept of ABCD, Always Be Collecting Dots, or information on your guests, so you can surprise them in wonderful ways.

The Ideal Team Player

I often reference Patrick Lencioni’s 5 Dysfunctions of a team, and have even created exercises around them. But surprisingly, I’ve never read through this other gem by Lencioni. Using Lencioni’s fable format, he posits that team players must be humble, hungry, and smart. My mentor was a huge fan of this, but looking back, I don’t think he hit all 3 of these attributes, underscoring how difficult it is to achieve all 3 attributes.

The Subtle Art of Not Giving a F***

Despite the vulgar title (and the book itself is quite vulgar too), the book lays forth a simple premise: we can only care about a limited number of things. If we stretch ourself to thin and try to care about everything, then can we truly live the life we want?

ANother great thought from this book is that life is about solving problems, but these will invariably lead to other problems. Need a new cell phone? Getting one will then lead to new problems around the new phone: charges, getting data migrated, apps installed, etc. The phone you have, is the phone you complain about. At a certain point, do the new problems need to be solved or can they be accepted for what they are?

Mindfulness: A Practical Guide

Emotional Intelligence has been a big push for me this year, and I continued that trend by picking up this book, which provides scientific arguements for practicing mindfulness through meditation techniques, but also by taking pauses throughout the day. This book provided a number of great techniques and exercises to be mindful, and will be a great reference for the future.

How to be Calm

This quick read provides a number of calming exercises and thoughts to consider to relax and live a calmer life. When stressed, I can flip through the book and find a thought or an activity to do to calm myself down, such as visuallizing your worries trapped in a helium ballon and see them float away.

Budhism Day by Day

When you think of Budhism, one often conjures to mind visions of monks in mountain temples spending their days meditating. But what does Budhism really teach and what is it about? That’s what motivited me to read through this book. This book provides various saysings and statements inline with Budhism, one for eacy day of the year. Each day gives you something to ponder over throughout the day.

Poorly Drawn Lines

I actually bought this for my wife, but this was just a fun book to read through, with a mix of comics and short stories.

… And then you die of Dysentery

This fun little title shares little life lessons inspired from the quintessential video game “Oregon Trail”.

The Princess, the Scoundrel, and the Farm Boy

This is a fun novelization of the original Start Wars movie, told from Princiess Leia’s point of view, then Han Solo’s, and finally from Luke Skywalker’s point of view. It included fun little tidbits, like Obi Wan whispering to R2-D2 that “It’s good flying with you again, my old friend.”

Pete Rose: An American Dilema

I grew up near Cincinnati, and fell in love with the Reds and all of their baseball history. But growing up in the late 80s and into the 90s, I knew little about Pete Rose other than his records and his ban from baseball. This biography of the baseball legend told of his drive to win, his faults, and how the led to his ban and how they perhaps hindered any lifting of his lifetime ban.

Writer’s Bootcamp 2

I picked this up at Barnes and Noble because I wanted to write more, and this book, along with cards with writing exercises, purported to help with that. This book gave practical tips on finding time to write with a busy life, which I desperately need.

Writing what you Know

I picked this book up, thinking it would help me develop my writing skills for my blog. However, the advice in this book is aimed more at fictional stories drawn from events in the author’s life. This book included some writing exercises. A decent read, just not what I was looking for.

The Inner Game of Tennis

Aimed at aiding Tennis players help manage the game in their heads between the concious self and subconcious self, this book provides aids to quiet the inner critic (concious self) so that you can perform at your best. The concious mind isn’t the best at direction actions, which is why muschle memory should be trusted to execute. Does this apply to knowledge work too?

Servant Leadership in Action

My mentor bought this book for me as a gift and I’m so glad he did. It was a fantastic read. This book contains dozens of essays on Servant Leadership from many different, well known leaders in many different fields. THis book is an inspiration to keep moving forward as a Servant Leader, as it shows you are in very good company.

Clean Code

It’s a bit of a travesty that I did not read this book sooner. I’ve known of it and the autor, affectionately known as Uncle Bob Martin, but the wealth of technical best practices held within were a treasure trove. Gems around providing clear names for everything, refactoring until the intent of code is clear, and explaining how a coder will writer code, but a Software Engineer will engineer code.

Power or your Potential

I picked up this tiny book, and it contains good tidbits on increasing what you are capable of in some key areas as well as some “elective” areas. I’m currently revisiting a number of these in 2019, and have tagged a number of activities to dive into from time-to-time.

The Power of your ptential starts with your energy potential: how much energy do you have accessible for tasks. One interesting trick is to consider how accessible the tings that energize you are. FOr instance, if family energizes you, but you live 9 hours away from them, your energy recharge is not readily accessible.

I Moved Your Cheese

THis was such a short read that I almost forgot I read it when I compilled this list. This fable follows a similar pattern set forth in Who moved my Cheese, except instead of playing the victim of change and then embracing it, this book questions, is the maze even real? How can a mouse escape the maze? Could they become a force and ultimately ‘move’ the cheese themselves, instead of waiting for others to move it on them?

I like this fresh take on this idea, because sometimes, we CAN move the cheese ourselves.

Leading in a Culture of Change

As an agilist, we find ourselves leading organizations that must embrace change and often find ourselves acting as “change agents”. That was what drew me to this title when I came across it in an outlet store. The autor splits his time discussing change in schools and businesses and takes a dry, academic view. This viewpoint makes sense given the author’s academic background. This was one book that I struggled through and did not gain much by reading it.

The Four Agreements

Subtitled “A practical guide to personal freedom, this book in some ways is about Emotional Intelligence, though I do not recall that phrase ever mentioned. The 4 agreements are commitments that one should make to oneself in order to live a better live. As a spoiler, the four agreements are “Be impeccable with your word’, ‘Don’t take anything personally’, ‘Don’t make assumptions’, and ‘Always do your best’. I personally struggle with many of these items. I tend to jump to conclusions often and will take things personally. Unfortunately, I did not find many practical suggestions to adhere to these, but mostly reasons why I should.

Coaching Agile Teams

In the realm of Agile Coaching, Lyssa Adkins stands out as a thought leader and expert. On Safari Quque, they include both her popular book Coaching Agile Teams and a video series that accompanies the book. While I’ve watched the series a while ago, I finally completed her book. While some of the chapters are drawn out, she has a down-to-earth style that I appreciate. And her coaching advice around pausing to consider if things need to be addressed now as a great take-away.

Accelerate

Our technical leaders in our group choose to read this book, as it coves many aspects of DevOps, but takes a very scientific approach to get there. WHile dry at times, especially in the latter parts of the book, it does present a number of good insights, such as 4 critical measures: Delivery Lead time, Deployment Frequency, Time to Restor, and Change fail rate. These are key measurements because they show what we value: rapid response, quick delivery, and high quality.

Power of Positive Leadership

Last year was a time for change in my work place. And while I’m a change agent, I don’t like it when lots of things are changing around me. “People don’t fear change, they fear being changed.” is an apt way to describe me and my work life last year. But being negative is not an effective way to lead. THis book provided good argument for leaders being positive in the face of change. The author has written, spoken, and consulted quite a bit on the subject, and this read like a “best of” book.

The Energy Bus

One of the other books by the author of Power of Positive Leadership referenced was this book, The Energy Bus. In this fable, a leader has a critical project to finish, yet everything seems to be falling apart: his job, his marriage, and his car. While resorting to taking the bus to work one day, he stumbles upon “The Energy Bus”, where over the course of several trips, he learns the rules of the bus to ensure he and his team embrace their challenges with positive energy.

eXtreme Programming Explained

XP was the first agile framework I heard of and utilized, back in 2004. While P has evolved over the years, at its core, which this book covers, is common sense team dynamics and technical best practices. What I find refreshing is the author’s stance that teams start where they are and add the concepts that work for them. This matches with my view that teams should make concious decisions on how they will operate, only selecting those practices that will help them and not just do something because a coach or trainer told them to.

Soar!

I was intrigued by this book and its promise to help find your vision and soar. Also hearing the author TD Jakes speak at GLS 2018 helped make the decision for me. This book is a great guide for someone who wants to start and operate their own business. Using the metaphor of an airplane, the author talks through many of the challenges along the way to get your business to soar. Sadly though, I was on my own to find and develop my vision.

“Life’s most persistent and urgent question is, ‘What are you doing for others?” ~ Martin Luther King Jr.

Servant Leadership looks different to every person. Some view it as an assistant asking or doing tasks for others so they can focus on what they do best. Others see it as putting other people’s needs before the servant leader’s needs. Still others see it as “leading from the front”, while others see it as leading while keeping in mind those that follow the leader.

While there is truth to all of these views, we can better grasp a topic like Servant Leadership by looking to examples of Servant Leadership today and throughout history. Martin Luther King Jr. provides us one example of Servant Leadership that we can emulate. While Americans often remember him for his “I have a dream” speech and his non-violent approach to leading the civil rights movement in the 1960s, he didn’t just lead this movement, but served it too. He was arrested 30 times while participating in protests, serving those that he lead.

He was a man with a singular vision, a world where people are judged on their charecter and not the color of their skin. But he also knew the way forward, through non-violent protests and civil disobedience of unjust laws. He was a leader who had vision, knew the way forward, and served others in ultimate service to his vision to change the world. While the entire world may not have achieved the vision he set out, it has been transformed by it and the way he worked towards it.

And remember, “Everybody can be great, because everybody can serve.”

Since 2013, my employer has hosted an Open Space conference, bringing together Agile Coaches and Practioners from across the company. Due to logistical issues, we weren’t able to meet in 2017. But, being the innovative type, I suggested we meet virtually instead and keep the spirit of learning and collaborating alive.

Why

Hosting a Virtual Open Space is not difficult, but why would you want to and what is it?

Open Space Agility is a framework for adopting agile while gaining grass-roots support. Instead of ‘dictating’ agile, Open Space Agility invites participants to write the story of how agile will look and feel in the organization. This is done through an initial “Open Space” event, where the participants are invited to attend, define the agenda collaboratively, and identify experiements to run over the next several months. A second “Open Space” event closes the first chapter of agile adoption, while also beginning the next chapter.

Through these Open Space events, participants not only discuss how their agile adoption can evolve, they also get to learn from each other and collaborate. The event offers an opportunity to break from the day-to-day operations, take a step back, and see how the organization can grow on the next step of the journey. And the participants are the driving force behind the change. I personally think this is the secret sauce of an Open Space; by inviting particpants to define how the organization will change, participants own the change. As Peter Senge once said, “People don’t resist change; they resist being changed.”

But in agile, we value “Face to face conversations”, so why would I want to do a virtual event? Well, in the global economy we live in, most companies have more than one location and budgets can constrain travelling to meet face to face. And while the first few Open Space events should be held in-person, once individuals from across the organization have built relationships and agile adoption is moving along, a virtual event is a great way to still get together and keep the experimentation and collaboration moving, while keeping costs low.

How

So how do you go about running a Virtual Open Space event, From my experience, you need 3 things to be successful, and handy enough, they all start with ‘M’: Marketplace, Marketing, and Meeting.

Marketplace

For the Marketplace, you need some way to aggregate topics, get votes, and determine how the agenda will be built. We used Jive to aggregate and vote on the topics, but I’m sure you have a similar tool that you can use. Or, you can aggregate topics via email and allow voting via a survey. There’s plenty of options here.

As for building the agenda, here’s where I departed from the traditional Open Space format. I ordered the topics by vote/interest, and placed the high interest items in my first track, the next highest items in the 2nd track, and so on. I tried to place the highest voted items at the best times - I figured the beginning of the day, before lunch.

Alternatively, and much more in the spirit of Open Space Agility, you could convene a meeting with the topic submitters and build the agenda in that meeting. Logistically, it’s tougher to get people from all across the globe together for a 30 minute meeting. Collaborating on the agenda can also be done via email or chatting channels.

Marketing

The biggest challenge we had with the virtual event was in the form of Marketing. How do you market an event of this size to everyone who might be interested? I tried a viral approach, with some success. We are attempting a virtual event again, and this year, we’re going more targeted to the attendees of the last Agile Open. These attendees have already meet face-to-face, are familar with the Open Space concept, and are motivated to learn and collaborate… all key aspects that you want from attendees to a Virtual Open Space.

I’m no expert on marketing, but here is where I would lean on volunteers to spread the word about the upcoming event, the virtual Marketplace, and the agenda creation. With a core of volunteers, flyers can be made and posted, reminders in email or chatting tools, and face-to-face conversations to drive excitement and awareness of the event.

Meeting

Depending on your tooling, this could be a big challenge. What web conferencing tools you have can impact the Meeting or virtual event itself. We were lucky last year in that we had BlueJeans accounts to use - and the system didn’t break a sweat with 30 to 50 attendees at once. Whatever tool you have, you’ll want to make certain it can handle the load you expect. From my experience, some tools work well with a handful of particpants, but that we start to have problems with the tool performing well when we have 10 or so attendees.

Of course, there are ways around tool limitations. Something I tried with limited success was to have volunteers at each location book rooms and run the conference largely from different conference rooms in each of the locations. The success of this will go back to Marketing as well and how many volunteers you can get.

But, if you have a tool like BlueJeans or WebEx, you should be ok with a few dozen individuals on 1 conference line.

Final Thoughts

Open Space events are a great way to learn, collaborate, and define experiments for your agile journey. But, holding 2 or 3 events a year in-person can be cost prohibitive. Switching 1 or 2 of these events out for a Virtual event can be a great way to keep the conversations going, keep agile growing, and to keep costs in check.

If you try it, let me know how it goes.

An Agile Transformation touches and changes many roles. Software Developers and QA Engineers are put together on the same team and the wall between them is torn down. Business Analysts are either made part of the team, or, as I’ve seen happen often, are turned into Product Owners and given ownership of the product. Someone, whether an up-and-coming leader or perhaps a Project Manager, is made the “Scrum Master” and told to facilitate the team’s meetings. And as for Project Managers, they often find a new role within the organization.

But what of the role of an Engineering Manager? Agile doesn’t do away with the need for managers, but frameworks like Scrum don’t provide guidance for these individuals on their role in an Agile organization. And that’s a shame, as an team’s agility relies heavily on the support of management. I mentioned previous that the role of a manager is to coach, mentor, manage their team and shape the organization’s culture. But, to do that effectively, one must have a good grasp on the concepts in agile, and that’s where these resources come in.

The Agile Mindset

Agile is a new way of thinking and organizing the efforts around delivering value to customers. It changes the relationship between developers and customers. It focuses on building trust, being responsive, and working iteratively. This is the Agile Mindset, and it requires a radical shift in thinking.

One good resource on the Agile Mindset and agile in general is Mike Cohn’s Succeeding with Agile. The first 5 chapters provide a good introduction to agile and challenges in adopting it. Chapter 12 discusses how to lead development teams and introduces the concept of Containers, Differences, and Exchanges to shape a team.

Lyssa Adkins has a video series on Safari Books online that is also very good. It is aimed more at Scrum Masters and Coaches, but I think there are a couple of lessons that managers can learn from as well.

Lesson 2 talks about the agile mindset and how we planning shifts.
Lesson 3 discusses what behaviors need to change when adopting Agile.
This portion of Lesson 5 talks about coaching a manager into becoming an agile manager.

Scrum

There are many good books out there on Scrum, but the first place you should start is by reading through the Scrum Guide. It is short, but don’t let the simplicity fool you, there are powerful concepts in here. I recommend reading through a couple times and watching a few videos online that draw out the framework, until you feel comfortable drawing the diagram out yourself.

While books are good, perhaps you want a class or a certification to show that you understand the Agile mindset. Scrum Allaince’s Certified Scrum Master class and certification will cover the basics of Agile and help you down the path of understanding agile.

Scrum.org has a couple of good certifications that allow you to demonstrate your knowledge of the Agile mindset and Scrum. Their PSM-1 Certification does not require a training class, if you prefer to self-study. This exam tests your Scrum knowledge heavily.

If you want to demonstrate your Agile Mindset and Agile Leadership knowledge, then look into Scrum.org’s Professional Agile Leadership Certification, or PAL 1. You can take this certification without the course and just read through the suggested reading list. However, if you can manage to take the course, you will receive a free retry of the certification exam, so long as you take both exams within 30 days of the class.

Servant Leadership

The Agile Mindset is a tough concept for many to grasp, but I find the concept of Servant Leadership equally difficult to grasp. Servant Leadership can be simply stated that a leader should look to serve those whom he or she leads, instead of looking to have those people serve the leader. I’ve written on Servant Leadership before, which includes the idea of treating leadership as a host of a dinner party and my personal favorite, leading by intent just as Captain David Marquet describes in his book Turn the Ship Around.

You may be skeptical that Servant Leadership could really work. Looking at the examples of leadership set forth for us by previous generations, we have many command and control leaders from which to draw inspiration from. But, the truly inspiring leaders are those that serve their followers instead of being served. The book Servant Leadership in Action puts this on great display through dozens of essays from leaders across many different industries.

Conclusion

There are a number of resources available for one to learn the Agile Mindset, Scrum, and Servant Leadership. You will undoubtedly come across others that speak to you. But the books, trainings, and certifications have been the most impactful to me, and will make an impact on you as well.