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.

A colleague asked me recently for some ideas on how to measure a team’s agile health. Like anything in agile (or in life, really), there are multiple ways to accomplish the objective.

One easy thing to measure is each team member’s satisfaction or happiness. This can be as simple as having each Scrum Master do a quick fist of 5 vote on happiness, with 0 or 1 being miserable, and 5 being very happy. The thing you have to be careful with this metric is that it doesn’t indicate an issue with a team. A low score could be due to an issue with leadership. Perhaps leadership has done something that the team is unhappy with. Perhaps leadership has set a team up to fail by placing people whose personalities just don’t go together. Or, perhaps the team is unhappy with themselves on how THEY are performing.

Mark Griffiths “PMI-ACP Exam Prep, 2nd Edition” suggests an interesting success metric for a team’s agile health - it boils down to 3 simple questions:

* Did the team deliver on what the customer wanted?
* Did the team leadership stay intact?
* Would the team operate in the same process again?

Unfortunately, this is a lagging metric and doesn’t allow you to pinpoint where a problem exists -it simply tells you if a problem exists. But, it’s simplicity does make it an attractive option.

A third approach is to present to the team the 4 values of the Agile Manifesto and ask each member to rate the team or organization on each of the 4 values. This will help you pinpoint where a team is unhappy, but if team members have different opinions of what the 4 values mean (and they will), you will get varying scores and opinions. But, this is pretty simple to do and you can track it over time.

A fourth tool for assessing agile health of an organization is this model called “Agile Fluency”. There are coaches who can come in and “assess” your organization, or you might be able to do it yourself. It’s an interesting model, but I haven’t used it myself. I’ve found more benefit in using it as a model for growing teams and generating ideas around how I can coach them to reach the next level.

The final tool and one that I’ve used for a while now is called Agility Health Radar. It’s not cheap… in money or time. It costs about $1,000 to become certified to facilitate the assessment and an on-going licensing fee to the tool. But this tool provides a clear visual on how the team feels like they are doing and provides them insight on how to improve.

The Agility Health Radar starts with a facilitated survey by a Certified Agility Health Facilitator. This survey lasts about an hour, and with the latest update, provides clear guidelines on how a team scores themselves in various areas such as “Generalizing Specialists”, “Predictable Velocity”, “Creativity”, and “Technical Excellence”. Once the team completes the survey, they then review the results as a team, discuss what they can improve, and raise concerns on impediments to their growth to their leadership team. These “Organizational Growth Items” are then discussed with the leadership team to be discussed and possibly resolved.

There are a number of ways in which an agilist can measure a team’s agile health. The approach you take will depend on your budget and time that you can invest into the approach. I recommend starting with asking the team how they feel they are doing on the 4 agile values. You can expand this to the agile principles, Scrum values, Lean-Agile values, or whatever else the team or organization values. Just like anything in agile, start small, experiment, and iterate.

How does someone get better at a skill? A new skill might require initial education, training, reading, watching, and thought to get to the point that the skill can be utilized. But regardless of a new skill or old, the only way to improve the skill is through dedicated time for practice. I can read all that I can find on improving my golf game, such as good swing techniques, or how to play various shots, but unless I practice, swinging the golf club or playing various shots, my golf game won’t improve.

But you might think you’ve reached the pinnacle of a skill and have no room for improvement. You’re like a professional at that skill, and professionals don’t spend time on practice.

Or do they?

Do professional athletes practice? They’re skilled at their profession, enough to put it on display each game. Do they practice? Of course they do! There’s always a move they could do better, be faster at, or understand the situation better.

Writing and designing software is a skill, a skill that we often take for granted. Once we’ve mastered a framework, library, development methodology, or tool, do we take time out to get better?

What we need is a method to practice these skills in an environment that allows us to refine and improve them. A series of software problems to solve, design, and code allowing software developers and testers a chance to improve in whatever framework, library, methodology, or tool they choose.

Put this all together, and you get the concept of a Code Kata - software problems that teams repeat to improve their skills.

Take some time out of your busy work week and try a code kata for an hour or two. And I challenge you to see if it improves your coding and designing muscles.

There are a number of resources on Code Katas. A few of these I’ve found include:

[http://codekata.com](http://codekata.com)
[https://www.codewars.com](https://www.codewars.com)
[https://github.com/gamontal/awesome-katas](https://github.com/gamontal/awesome-katas)
[https://github.com/pivotal/code-katas](https://github.com/pivotal/code-katas)
[http://www.codekatas.org](http://www.codekatas.org)
[http://codingdojo.org/KataCatalogue/](http://codingdojo.org/KataCatalogue/)

Good luck and happy coding!

When tackling a new project, feature, or application, it’s often useful to define a ‘minimum viable product’ or a ‘minimum viable feature’. The pure essence of this idea is to identify the minimum amount of requirements that produces a valuable and usable product. This ensures we focus on just a few features and deliver them quickly. Ultimately, we want maximize the value we provide, which means we may not implement all of the features we have planned. To truly maximize the value teams deliver requires a critical eye on requested features and a product team that is not afraid to say “no”.

While we strive for that level of rigor in our product backlogs, do we enforce the same level of rigor in our agile practices? As we add more teams to an organization and add more coordination points, we may be tempted to reach for some scaling agile practices, such as Communities of Practice or Scrum of Scrums. We may even reach a point where a scaling framework like the Scaled Agile Framework (SAFe) or Large Scale Scrum (LeSS).

But we should hold ourselves to the same level of rigor with our organizational changes as we do with our product backlogs. That means we should aim for minimum viable scaling; the least amount of scaling we need to achieve value from it. That means we need to say “no” to some scaled agile practices and aim to implement the most valuable ones first. Our aim in our scaling efforts should be the same as with a product backlog: focus on what gives us our ‘biggest bang for the buck’ first.