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.

Inside every agile organization, there lurks an ever present dilemma. This dilemma never goes away. It will always be a source of struggle, either big or small. At times, it may only restrict ‘how agile you can be’. At other times, it may challenge the entire agile transformation itself and rock your organization to its very core. The dilemma I speak of is the role of an Engineering Manager.

The Scrum Guide, when it outlines the roles on a team, excludes the role of an Engineering Manager. The Scaled Agile Framework, with all of it’s documentation, outlines what Lean/Agile Leaders look like. Extreme Programming is also quiet on the role of an Engineering Manager.

And in a lot of ways, this would make sense. These agile frameworks aim to appeal to as large of audience as possible. If they take a stand on the role of an engineering manager, they risk alienating potential users of their framework. Discussing the role of the engineering manager gets into very dangerous territory - office politics.

And that is a shame, because your leaders, at ALL levels, can make or break your agile organization. If you have even 1 manager who doesn’t “get” agile and their role in it, it can have disasterous results. Especially if that behavior is inadvertently praised and rewarded.

So what is the role of an Engineering Manager? It is to mentor, coach, and manage the engineers in their charge. Junior engineers need to be mentored in a variety of areas of the craft of software engineering, including working on a team, reviewing code, validating a change, and of course, designing and writing code. These aren’t trivial skills that one picks up overnight, and a young engineer will need help as they learn to master these skills.

Those who have the basics down still need correction on various different points now and then. Here, the manager can coach his team members and help build them up on areas where they struggle. This can take the form of gentle encouragement, reading assigments, pairing with a peer on the subject, an open discussion, or even formal training. Here, the manager can get creative in the way they build up the skills of their team frther.

Finally, an Engineering Manager must manage those that report to him or her. This includes hiring, firing, promotions, reviews, and any other HR responsibilities. Depending on the organization, these responsibilities may vary, but most are universal to any management role.

Outside of the team, an Engineering Manager has a duty to the larger organization. Here, he or she must work with other leaders to foster a culture conductive to the goals of the organization. In an agile shop, this means working to foster a culture that supports the agile values and principles. Beyond this, perhaps an organization also wishes to foster innovation. In that case, they would do well to build a psychologically safe environment. Or, perhaps they need to reinforce accountability, in which case they could take inspiration from Chris Avery’s Responsibility Process or through books like The Oz Principle.

Before concluding, I’d be remiss if I didn’t share what 2 other agile thought leaders have considered on this topic. Sally Elatta, President of Agile Transformations, a company focussed on Agile training, coaching, and tools, wrote a great article stating that the role of a manager in agile shifts from being tactical to being strategic. With the team being empowered to self-organize around the work, a mature team needs little guidance in the tactical, day-to-day work.

While not discussed directly in the Scaled Agile Framework, this article regarding the evolving role managers from SAFe describes many responsibilities a manager in a SAFe implementation can and should take on to support the SAFe implementation. This too provides good guidance and includes good tidbits, such as working to build a DevOps infrastructure and culture, regardless of whether you follow SAFe or not.

In an agile world, the role of a manager is not easy. To support the fast pace of change, the manager must be as nimble as their team. Just as the role of engineers change as a company moves to agile, so to does the role of the manager. But I think the biggest challenge AND the biggest reward, is that the role of a manager will change as the team matures. As the team takes on more responsibility for themselves, the manager can broaden their role to take on other responsibilities. And it is here that the manager can turn a challenge into an opportunity for themselves and the organization.

I once had a Developer on my team, a wicked smart and funny guy, whom I was coaching on agile. He was brand new to agile, but certainly no stranger to wit. After introducing him to the concept of user stories, story points, and planning poker, he one day coined a phrase, “It’s agile, where the stories are made up and the points don’t matter”.

Proponents of the #NoEstimates movement, agilists who believe that story points are unnecessary, would probably agree with the second half of that statement. (On the other hand, those who dislike agile and/or product people, might agree with the first half of that statement, but that’s another blog for another day.)

At an annual Agile Open conference, I sat in on a heated conversation around estimates. Some argued for pointing in story points and then hours, while others argued for not pointing stories at all. I’m not sure how the first side felt after the conversation, but I know the second side walked away frustrated and turned the conversation into an inside running gag for the rest of the conference.

At this conference, my role was to sit back, assist the facilitators where needed or asked, and just observe. And in this session I did, while munching on some metaphorical popcorn. But what both sides missed is that all forms of estimation or no-estimation are valid, but, it is a spectrum of growth. New teams need the structure of story points, and even hour estimation, to ensure they have a grasp of the body of work in front of them. As teams improve, they can drop the hour estimation as their confidence in their pointing improves.

But a team should strive to continue their growth in estimation, story writing, and story splitting. Because on the end of the spectrum of growth is where the #NoEstimates lives. Here, a team is confident in 1) their ability to split work into it’s smallest possible chunk of value, 2) their ability to create these chunks about the same size as each other, 3) their ability to ensure each chunk fits within a sprint, 4) their ability to gain shared understanding of the story and 5) their own ability to execute and deliver the work the team commits to.

Story Points provide 2 benefits. First, they allow the team to determine how much work they can complete within a sprint. By knowing the size of their work, they can determine what stories will fit in the sprint, and what won’t. Story Points aren’t for “taking credit of the work we did” or “comparing 2 teams”, it’s simply to provide a way of knowing if the team has not enough work, too much, or just enough for their sprint. As a team matures, they can trust their intuition as well as the story count of how many stories they typically complete in a sprint as their measurements for what to commit to for the next sprint.

Most agilists intuitively understands this first point, but some miss the second benefit; it helps the team see if they have a shared understanding of the story. If you and I are on a team and estimate a story to be the same number, then there is a good chance that we both understand what it takes to complete the story. But, if you point the story as a “1”, and I point it as an “8”, then there is something that one of us doesn’t know or understand. Perhaps you know that this is a simple configuration change. Or, I know that the code doesn’t support this change and requires heavy refactoring of a critical area of code. By pointing, we encourage the team to raise and discuss areas of misunderstanding and diffences of opinion.

For a team to be ready to try #NoEstimates, they must be a well oiled machine, capable of splitting stories down effectively, intuitively knowing how much work they can take on (or not, if they are a Kanban team and don’t plan), and capable of getting to a shared understanding of a story without pointing. All of this requires a highly-functional team that has long since passed the “Storming” phase of growth. By understanding what story estimation provides besides an estimate, a team can move beyond estimates and focus more on the value the team delivers.

When an organization adopts agile as their method of working, it is said that they are going through an “Agile Transformation”. As if change isn’t difficult on it’s own, the organization must “transform” to embrace agile and this radically new way of working.

Agile Trainers and Coaches refer to a new form of leadership that is necessary for agile to flourish in the new organiztion. They call this “Servant Leadership”. Servant Leadership, simply put, is a mindset where the leader of the organization serves those he or she leads, all in purpose of a greater vision for the organization. This is often described as inverting the organizational structure by placing the leader at the bottom and the individual contributors at the top.

A recent book, “Servant Leadership in Action”, edited by Ken Blanchard & Renee Broadwell, contains dozens of essays on Servant Leadership, including Ken Blanchard, Brene Brown, Stepen Covey, John Maxwell, Simon Sinek, and many others. This book, with it’s dozens of authors, contains just as many different view points on Servant Leadership.

While Servant Leadership is the classic leadership style that Agile coaches will teach, there are other, similar, ancillary leadership styles that are close-enough to Servant Leadership to be considered: Host leadership and Intent-based Leadership.

Host leadership comes from the book Host, which describes leadership as a host of a dinner party. Just as a host at a dinner party ensures that the guests are fed, mingling, and having a good time, a leader makes certain that team members are motivated, collaborating, and delivering value. The metaphor of a dinner party host is simple to explain and easy to grasp.

Intent-based Leadership, on the other hand, comes from Captain David Marguet and his book Turn the Ship Around. In the book, Captain Marguet describes how he led the USS Sante Fe, at times out of necessity. In this leadership style, it is the leaders job to communicate the vision of the mission at hand, and those following to determine how to accomplish the goal. This is often done by informing the leader that “I intend to…”, with the leader then asking questions to ensure every angle has been considered.

But with so many different resources and different views on Servant Leadership, all agilists must be great at Servant Leadership, right?

Unfortunately, where I see agilists and agile organizations fail the most is in their adoption of Servant Leadership. There’s so many different ways to get it wrong, yet only a few ways to get it right. But more critically, Servant Leadership is a mental shift, one that takes place over months or years. Growing up, we had plenty of experiences being lead by command and control leaders: our parents, our teachers, our little league coach, our scout master, and later in life, our boss and managers. We’ve unfortunately have few examples in our life of Servant Leaders from which to draw inspiration from and model in our lives. Perhaps you had a spiritual leader, or a truly inspiring, serving school teacher to emulate. But all too often, these guides are drowned out in our heads by ALL of the other examples of leadership we’ve experienced.

Ultimately, a shift to Servant Leadership doesn’t easily occur by reading books. It needs 2 things to prosper. First, you have to already have strong Servant Leaders who can coach and mentor those who struggle with this new reality. Because Servant Leadership is best grasped by being experienced, not by being read in a book. And with a weekly guide, small strides can be made in the organization lifting all leaders to be servants.

Second, and most importantly, the organization must value and reward servant leaders. If leaders recognize and/or reward leaders for demonstrating behaviors counter to servant leadership, such as committing dates on behalf of a team, pushing teams by saying “just go faster”, or by micromanaging team members, the organization will get more leaders like this. And when an organization has more leaders like this than servant leaders, you can be sure that their agile transformation will struggle and may ultimately fail.

My favorite part of being an agile coach is standing up a new team, whether it is a Scrum team, a Kanban team, or a Release Train team. It involves bringing together a group of individuals and getting them to operate as a single unit, towards a single purpose. And, it involves finding creative ways to bring people together.

The task of setting up a team varies based on the situation, the individuals, and the organization. But regardless, of the specific situation, I follow a 3 step process to standup a new team: make the group a team, make them an agile team, then make them a [insert framework here] team. My reasoning is quite simple: a Scrum team that is not also agile is missing the point of Scrum, and an agile team that does not operate as a team will struggle to function effectively.

In Part 1, we’ll discuss how to setup a team. In Part 2, we’ll cover how to make a team an agile team and how to make an agile team a Scrum Team, a Kanban Team, an XP Team, or even a Release Train Team.

Create a Team

When it comes time to kickoff a new team, I look to establishing the group’s identity, setup ground rules, define processes for collaborating, and for the team to learn about one another. It is this final piece - learning about one another, that becomes crucial to establishing a team. But all of these elements are necessary for setting up a team for success.

Group Identity

A group’s identity can be as simple as establishing a team name, or as complex as defining a mission statement, envisioning the end state, and establishing the team culture. I find that the team culture will evolve as the team grows - but a good name is a great place to start. It is the start of an identity, one that the team will build upon as they work together.

The first Scrum team that I coached picked the name “The Avengers”. From this, the team decided that each team member should pick a member of the Avengers to be their avatar. Anywhere in our development tools, it was easy to spot our team members, as we were the superhero team, working together towards a common goal. The morale of the story: find someway to incorporate the team name into the identity of the team.

Ground Rules

Any collection of people working together need to understand the boundaries of that group - the rules that define how interactions work. As human society developed and evolved, the rule of law helped govern people’s behavior and led to a well-ordered group. With a new team, we need to take time tto define how we will operate.

As we start up a new team, setting aside ground rules for how the group wants to operate jumpstarts the groups formation by codifying some of the expectations the group has on eachother. As the team starts working together, they may discover additional rules they would like to establish to frame how they work together. Feel free to add these to the list of ground rules, but be cautious about adding TOO many rules; you and the team will likely forget one or two and will decrease their value.

If your team is a multi-cultured team (meaning, not everyone hails from the same country, region, culture, etc.), you may need to discuss the different expectations of each person’s culture. For instance, some rules are so ingrained by an over-arching culture, that they are only noticible when you interact with other cultures. For example, Americans have a preference for a large amount of personal space, but going through our day-to-day lives, this isn’t noticeable until you encounter someone from a different culture that has a different view on personal space. Then, their closeness can be a bit unnerving to an American. These cultural differences will surface as the team begins to execute, but it may be worth while to discuss the groups cultural differences and decide how to resolve any challenges this presents.

Collaboration

As you move into how the team operates, you’ll begin to touch on the agile processes and practices that define the team. We’ll cover these more in part 2, but for now, let’s consider how does the team collaborate? In this part of the kickoff, I discuss:

• What are our core working hours?
• Do we want to establish some “focus time”, time where interruptions are highly discouraged?
• What tools will we use to collaborate?
• If using group chat tools, what rooms/channels do we want to establish? What will their usage look like?
• Do we have a preference for when we schedule meetings? Mornings, Afternoons, a particular day of the week?
• Do we need a team home page in our wiki/SharePoint/Blog or similar tool the organization uses?
• Do we need a email distribution list?
• How will we communicate with eachother primarily? Face-to-face, email, chat, phone, video conferencing? When are the appropriate times for each of these channels?

Based on your organization, your own experiences, or the experiences of the group, you may think of other items to consider here.

Team Member Identity

While this is the final portion in my list, I view it as the most important part. For teams to truly work well together, everyone must feel comfortable being themselves and bringing that person that person to work. Innovation requires lots of ideas to choose from. But in order to surface many different ideas, team members must feel safe in bringing them up. If a team member can be themselves, and free to pull from their personal experience, we can generate more and better ideas. But this goes for EVERYONE on the team, not just the most senior person on the team.

There are many ways for team members to share with the team who they are: you can ask questions, ask each person to talk about themselves, have team members interview eachother, or play a team-building game. Here, your imagination is your only limit to what you can do.

I have 2 go-to strategies for the teams I work with: a personality test and a team member cereal box. For the personality test, I ask team members to take the free 16 Personalities assessment and share with the team. As each team member shares, we make connections, discuss what seems most true about the assessment for us, and discuss how we relate to the other personalities. Depending on the familiarity of the group, I may ask them to send me the results and I’ll read them off to the group and ask them to guees. In this way, we surface how others currently see us.

The other exercise, adapted from Lyssa Adkins’ book Coaching Agile Teams, goes something like this: provide each team member with a blank cereal box, a piece of paper or a poster board as well as some art supplies (colored pencils, markers, pens, etc.) and ask them to enviosion themselves as a product. What do skills do they provide? What is the experiences they bring? What is this person’s brand? But also ask them to focus on what they want to become. Do they wish they knew more about testing? Front-end development? Database design?

Once everyone has designed a cereal box or poster, ask them to share with the team. As people go around the room, ask the team to ask questions and to chime in where they can help the team member gain some of the skills they want to grow. Not only will team members walk away with a better understanding of each other, but they will have some ways to build upon the team bond as the team works together and helps each other.

Conclusion

Teams are amazing groups of people, but they don’t form overnight. Through establishing an identity, establishing ground rules, determining how the team collaborates, and learning about the members that make up the team, we can establish a good foundation upon which to build our agile team.

A friend and colleague posed the following question via a text message:

What are the leading indicators that a program increment or team will not deliver on their commitment? What metrics would you gather to prove them out?

Before I dive into my thoughts around this, let’s setup a couple of assumptions. First, let’s assume we have a Scrum team that is following the Rules of Scrum. But along side that, let’s also assume we have a team that follows the spirit of the Agile Manifesto. I talk more about how I stand up a new team and my ideal relationship between the Agile Mainifesto and Scrum here.

With a Scrum Team, their commitment to delivery is to their Sprint Goal. While they forecast the stories they will work on and try to complete, they still commit to delivering their Sprint Goal.

When a Scrum Team works in a Program Increment (most likely as part of an Agile Release Train in a Scaled Agile Framework implementation), the team also commits to delivering Program Increment Objectives, or PI Goals, statements that summarize the value they intend to deliver.

So how do we measure if a team is on track toward delivering Sprint Goals and larger Program Increment (PI) Goals?

Is a team on Track to meet their Sprint Goal?

There are a few indicators we can use to help us understand how a team is progressing towards their sprint goal. However, none of these are perfect. All that they allow us to do is to ask better questions.

Burndown (or Burnup) Chart

Burndown or Burnup charts have long been a powerful tool for agile teams to inspect how they are tracking towards completing the sprint. A typical Burndown or Burnup chart tracks how the team is progressing towards completing all of their stories within a sprint. If the team is on pace to complete all of their stories, that is a good indicator of success. Conversely, if the team is not on pace, that may indicate a problem.

However, there are 2 problems with Burndown/Burnup charts. First, despite efforts to complete work early and often in a sprint, many teams tend to complete more stories the last couple of days in the sprint. So, a team that appears to be off track might surprise you and complete everything.

Second, and perhaps more importantly, the Burndown/Burnup chart does not track completion towards the Sprint Goal, just the items that make up the sprint. The Sprint Goal might entail completion of 1 or all of the stories in a sprint, or somewhere in-between. So a team that completes just 1 story might indeed achieve their Sprint Goal, if that story was all that was necessary to accomplish the goal.

Injected Work

$#!& happens. An emergency issue occurs in production. A user story was missed. An important bug needs to be addressed now. Whatever the case, a team that operates in an agile fashion has to respond to change and bring in work into the sprint. We call this “injected work”.

Focus is one of the 5 driving values of Scrum. Injected work will force a team to lose its focus, which can jeopardize the Sprint Goal, the stated focus for the sprint. While tracking Injected work does not correlate directly to a team completing their goals, it can indicate trouble lies ahead.

A metric of a bygone age may also be useful here: defect rates. In a world of waterfall projects, Project Managers would track defect rates as an indication of progress towards completing a release. The idea being that once the level of defects found level off and no more critical defects exist, a project is ready to release. For Agile teams, tracking defect rates may also be useful, as this indicates quality of the product. Products with poor quality will likely have larger amounts of injected work, have higher technical debt, and cause teams to run into more issues as they progress towards their Sprint Goal.

Is a team on Track to meet their PI Goals?

Many of the metrics for a Sprint Goal can also be applied towards larger PI Goals. Burndown charts can be particularly useful, when the team identifies the critical path.

Track the Critical Path

Not all stories that a team plans in a Program Increment are critical to the success of the PI Goals. Some of them are simply “things the team needs to do”, like update code libraries, adhere to a new legal requirement, or address technical debt. But, there are other stories that are crucial to the success of a PI Goal, and these stories lay out a Critcal Path to the teams success. If we ask the team to identify this path for us, we can track it via a burndown chart and see their progress towards the end result.

Like any other metric we’ve discussed so far, this isn’t perfect. It’s possible for the team to identify new stories, causing the critical path to change. Depending on the goal, it’s also possible for the critical path to be completed, only to find out that we made incorrect assumptions along the way.

Actual Velocity vs Planned Velocity

When planning a Program Increment, the team plans stories based on their Planned Velocity, or the velocity they expect to achieve based on what they’ve accomplished in the past. By tracking the velocity the team planned to achieve vs their actual velocity, we can see if the team is accomplishing more or less than they anticipated.

Of course, by now you’re expecting me to state a negative to this approach, and this time it’s a big one. Just because a team is accomplishing a lot of work, it doesn’t mean it is the right work to achieve the Sprint or PI goal. It could be made up of injected work, technical debt, or simply stories that do not align with the team’s goals.

One Radical Idea

As we’ve examined a number of metrics, there have been issues that arise with each of them. So what is a team, train, or leader to do to tell if a commited goal is still achievable, in jeopardy, or out of reach? One radical idea is also the simplest: ask the team. In SAFe, we establish commitment to PI goals based on a confidence vote from the team. The team are the ones committing to the work and the ones closest to it. Thus, they should be in the best place to gauge whether the goal is on track or in jeopardy.

One Scrum Master that I work with asks the team for how confident they feel they can achieve the sprint goal at the end of a stand-up midway through the sprint. The team votes 1 through 5, and when a team member votes low, she asks what can be done to increase the teams confidence in reaching their goal. This is self-organizing teams in action!

Concluding Thoughts

We’ve discussed a number of different metrics. Each of them have their place, and can help you understand how a team is progressing toward their goals. However, all that these metrics do is allow a team, train, or leader to ask better questions. A team may be tracking perfectly towards their goal, but one missed story could cause the goal to be missed. Conversely, a team could have horrible defect rates, lots of injected work, and a poor velocity, yet still achieve their goal.

Ultimately, the team doing the work will have an idea of whether the goal is achievable or not. Teams tend to be overconfident, but that is where I see the value of metrics. Bring in metrics to challenge the teams confidence, but when they are still confident, leave them to the task of completing the goal. And if their confidence was misplaced, let’s ask why we were overconfident, so that next time, we can do better in achieving our goals.

I was in Elementary school, perhaps 4th or 5th grade, when I came across an interesting book in our school library. It purported to teach the reader how to make their own computer games. Using some derivative of the BASIC language, it provided tutorials and the code to do various jokes and simple games. I recall specifically one program that asked the ‘player’ to point to their head and say the abbreviation for mountain (which is MT) three times. Then, after a few seconds the computer program would print out ‘It sure is!’, as it had duped the player to saying their head was empty out loud.

And while it would be cool to say from that day I was hooked at writing computer programs, the truth is a bit different. Sure, I wrote a few dozen programs as a kid, but by the time I was a teenager, I had moved on to other interests until my senior year in high school, where I decided to take a programming course. This class was also based in BASIC and I took to it like a fish to water. It felt like an old friend, but with age came a better understanding of what I was telling the computer to do. Where before stood insurmountable obstacles to my understanding were now gateways to a brave new world.

When I applied for college, I opted to major in History, but this did not last. Before I took my first class, I was a Computer Science major and never wavered from that path.

In 2004, in a graduate level class taught by my favorite professor, we learned about technical practices, agile development, and something called “Extreme Programming”. This exposure to XP was the first time that I felt like a professional software developer in college.

During my senior year though, I faltered. Through ignorance on my part, I missed the career days and questioned if coding was really for me. I didn’t start my first job until 2 months after college, and then it was a job as a QA Engineer. It was at this time I wondered, “Why am I coding?” and decided to start my first blog of the same name.

For me, coding started as a hobby, and I’ve always worried coding professionally would cause me to lose my passion for it.

But regardless, a year after graduating college I transferred to a role in Software Development and worked on many different projects for a number of years. Most of these were “waterfall” projects. But, in 2009, struggling to keep track of so many tasks, I discovered Kanban and embraced it for managing all that I was working on. I even went so far as to build a Kanban board app in Ruby on Rails and hosted it kanbanfordevelopers.com. In 2010, I moved on to a new job, where I worked with Kanban until 2013.

In 2013 though, an opportunity presented itself for me to be a Scrum Master for a Scrum team. I jumped at the opportunity, as at the time, it was only a part-time role. I thought this new role would allow me to ‘come out of my shell’ and learn to exist in an extroverts world.

But a few months later, the organization decided it was time to have dedicated Scrum Masters, so I reluctantly gave up software development for the first time.

About a year later though, I was bitten by the coding bug again, and jumped at the opportunity to be a split Scrum Master/Software Developer again. This time, I had the added challenges of working with a team that was new to agile, the organization, and was tasked with maintaining a legacy system where we had no one to ask how things worked.

And this time was fun. Perhaps some of the most fun I’ve had in my professional career. But I came to realize that by being a split role, I was hurting my team, so I gave up software development for the second, and perhaps final time. But this time, I did it knowing why I was doing it: the teams I coach can only be coached effectively if I give them my full attention, I stay completely neutral on technical decisions, and I use my coding powers for good and not evil.

So why am I NOT coding? So I can best coach, help, and grow the teams I work with.