Traversing through Change

Two years ago, I attended Agile West, and my perspective on software development changed entirely. I was bombarded by so much material that is so blatantly obvious to me now. However, at the time it was revolutionary for me. As a tribute to my epiphany, I’d like to talk about the Satir Change Model. This model and a value driven illustration which I’ll discuss another time really sold me on the need for change. The graphic below is used by coaches and trainers to illustrate the treacherous journey; the change can be as simple as introducing Test Driven Development or completely scrapping sequential development. This isn’t earth shattering material, but I want to invite readers to read and reflect where they are on this journey. Allow your minds to picture where you are, where you were, and where you wish you could go. What did it feel like as you were looking over the edge? If things didn’t quite work out, why? What would you recommend to those about to embark on their own journeys?


It takes courage by an organization to implement change, and it takes an immense amount of intestinal fortitude to hold true to that commitment; nothing will test the will of leadership when the inevitable chaos ensues. Despite the many voices in the community yelling that ‘going agile’ is not a silver bullet, companies run straight off the cliff expecting immediate results. These companies are so desperate, they are willing to take the leap of faith without measuring the depth of the chasm. Can we really blame them? In some cases their situation was so poor, it appeared like their only option at the time. Going ‘over the edge’ isn’t something to be taken lightly, and it may not even be the best decision for your team or company. There is no fault in choosing not to make a change.

Then you have the organizations that invested the time upfront to prepare for the descent. They go as far as establishing a community to help scale the change. The community, rather than the individuals, improve the likelihood of the change ‘sticking’. They’ll collect some bumps and bruises on the way down, but they stay the course and arrive at the bottom of the chasm. The scars serve as reminders of why they chose to make the journey.

It takes a lot of hard work and sacrifice to complete the descent, but just because you reach level ground doesn’t mean it’s time to relax. In my opinion this is when the organization is most vulnerable- between the chaos and transforming idea. Organizations are not prepared for this ‘lost’ feeling and immediately start looking for more solutions. Some will turn right back around and ascend the cliff they just painstakingly descended- the rubber band effect. Others will try to redefine their goal and create an entirely new chasm of change; a short term solution with a much higher climb at the end. In successful cases, they manage to trudge onward.

The ascent is truly not for the faint of heart. Here, teams and organizations have experienced their ‘transforming moment’. This is like the first spark when trying to light a fire; you keep attempting to repeat whatever caused it to happen. Sometimes you’re successful, sometimes you’re not. In this phase, the teams and individuals can start to see and feel the change. Beware of bad habits and false ledges; they’ve sent many tumbling on more than one occasion.

Finally, you reach the other side. You’ve completed your journey… you’re agile. Wrong! At this point, you’ve broken even. Remember way back at the beginning when we all agreed, ‘In order for us to produce what we’re producing now, we have to take a dip.’ You’re back on level ground. However, your organization is now equipped with the experiences of this monumental change. You’ve likely had your share of successes and failures; each one serving as a lesson learned to strengthen your resolve. From this point on it’s about consistency and striving to improve- both are easier said than done.

I purposefully made this post brief and very broad. There are many strategies to clear the chasm.With these attempt come many stories of success and failure. We can gain much insight from analyzing the journeys of others. Where are you in your journey? Are you looking over the cliff deciding if this is right for you and your organization? Are you carefully making your way down… slipping every now and then? Are you lost at the bottom of the chasm? Or are you making that final climb?


TriAgile Recap

I had the opportunity yesterday to attend a local, yet large, agile event in Raleigh. Since I arrived in theIMG_0003 area, the TriAgile conference had received plenty of hyped from my co-workers. Well, I am very happy to say that the event lived it and more. The location, the Mickimmon Center at NC State, provided ample accommodations for all the attendees. Many kudos go out to the organizers and vendors that made this event possible. The attendance in its 2nd year doubled from 200 attendees to just over 400; they’re definitely doing a lot of things right. I was a bit concerned about cramming in 5 sessions along with 2 keynotes in 1 day. However, I was extremely surprised how smoothly the presentations flowed into the breaks and back into the next presentations. At no point did I feel rushed.

While I’m still riding the ‘Agile High’ I wanted to summarize the sessions that I attended. This technique helps me soak in all the information along with disseminate some of the great ideas shared. The conference offered plenty more sessions; these were the ones that I was able to view.


How To Build the Wrong Thing Faster (and learn from it) by David Hussman

I’m going to lead this discussion off with a warning: David Hussman was the first speaker that I listened to at Agile West 2013. If you read my bio, you’ll recall that this was my epiphany moment for my career in software product development. You can only imagine how excited I was to listen to David, now that I’m almost 2 years into my journey.

David hit on a variety of topics in his speech. He touched on how organizations are confusing large crowds for collaborating. He referenced how Pixar would allow its team of 200 to make suggestions, but in the end it was a much smaller subset that synthesized all those ideas into stories. As he usually does, David went on the offensive on a buzz term we hear so much in the software industry: ‘Do IMG_0165Scrum/Agile’. In reality, what does that even mean? As he stated in his presentation, Agile/Scrum are just words until we give them meaning. In his ‘Cutting an Agile Groove’ series he replaces ‘Agile/Scrum’ with ‘collaborating’. In reality, that is the true essence of what we’re attempting to accomplish. Organizations and many in the agile community have fallen into the process trap and have forgotten what we’re really doing- delivering working products.

David also invited the crowd to start looking at failure differently. In my generation, like all before me, failure was not an option. David tied it all together with a scientist metaphor. Scientists are wrong 99% of the time, but they never quit. In order to make strides forward, we have to experiment and make mistakes. Its through this trial and error that we make breakthroughs and innovations.

As expected, David kicked off the event with a bang and his discussion led the way for several of the other topics for the day.


The Backlog Refinement Meeting-also a diagnostic Tool by Arjay Hinek

As I warned you in the previous review, I’m going to warn you upfront on this one, as well. Arjay hired me as a ScrumMaster at Red Hat in November 2014. I consider him my mentor in my agile career; he has coached me for several months. Along with coaching, he has been a sounding board for many of my articles and presentations. For the first time, I was the spectator.


IMG_0004     Arjay’s presentation contained some very ‘meaty’ material, and his high-energy approach to the presentation kept the audience engaged and entertained. His presentation opened with a continuation of the theme of the opening keynote speech. Arjay encouraged ScrumMasters and coaches to break the monotony of iterations and try new things; sure, some of the activities and twists we try will fail, but we learn from those failure. The premise of his speech took us deep into the artifacts that ScrumMasters and coaches can gather by simply observing the backlog refinement meeting- which I truly hope all teams are holding.

Arjay conveyed how the backlog refinement meeting offers some interesting glimpses of the health of the team. Specifically, the health of the following can be deduced from the backlog refinement meeting: Product Owner, team, stories, and the ScrumMaster. Below are some examples from his speech:

  • Health of Product Owner
    • Can you determine vision by looking at backlog?
    • Has it been prioritized by P.O.?
  • Health of the Team
    • Team should be comfortable talking about tech debt with PO
    • Does team openly negotiate and prioritize tech debt
  • Health of Stories
    • Stop solutioning
    • Is the story about delivering the best solution iteratively?
  • ScrumMaster Assessment
    • Do they ask the right coaching questions?
    • Do they invite conversation or “shoot it down”?

Arjay wrapped up his presentations, by emphasizing the importance of assessment tools, and he encouraged us to use them.


Sustaining Agile Across the Enterprise: An Executive’s Point of View by Andy Diggelmann

Next on the list was Andy Diggelmann’s presentation on agile from an executive’s point of view. I was curious to hear what Andy had to say; in my experience, the executive level has always been the challenge for Agile transformation and sustainability. I hoped to get into the head of an executive and see things from their eyes. This would give me valuable insight into the concerns I can address in the future while assisting organizations that are just starting out their journey.

Andy delivered an impassioned speech about the benefits of Agile at SAS and his company’s journey over the last 15 years. He encouraged the executives and future executives in attendance to allow things to flow organically after a transformation. Andy also highlighted some of the key benefits of an organization’s adoption of a more collaborative environment: change, transparency, and innovation. He also warned us of some pitfalls to avoid during the journey. Specifically, he mentioned that there is no ‘one size sits all’ solution and that there is no room ‘to do things by the book and hide behind agile’.

When the presentation opened up for questions I asked Andy what made him the most skeptical of the Agile transformation as an executive. He quickly referred back to his slides on anti-patterns. The idea that there was no central control and a high possibility of chaos in the organization was the most unnerving feeling for Andy. However, the benefits, such as transparency into product development, heavily outweighed his concerns.


Key Skills for Managers and Leaders in an Agile World by Devin Hedge

Devin Hedge’s presentation intrigued me. As he dove deeper into his topic, he started hitting a topic that has been a bad rub for me over the years. His message paralleled my views that employers still value content/technical skills over core/soft skills. This makes sense for new employees, but does not fit for leadership. I used to agree that a professional should place no responsibility on the employer for growth. However, after spending 6 months at Red Hat, that view is quickly changing. Red Hat explicitly encourages its employees to stretch beyond their job titles and professional capabilities. In many cases, Red Hat will provide the means to build their employee’s professional careers. As a result, it has built a loyal, diverse workforce that knows their employer recognizes the daily sacrifices they make in order to make the company successful. This is contradictory to what Robert Martin states in his book Clean Coder:

“It is not your employer’s responsibility to make sure you are marketable. It is not your employer’s responsibility to train you, or to send you to conferences, or to buy you books. These things are your responsibility. Woe to the software developer who entrusts his career to his employer.”

     I cannot claim that Martin is incorrect; to expect these ‘perks’ from an employer is unrealistic. However, I firmly believe that a company that truly cares about its workforce will provide these to its employees.

How does this tie into Devin Hedge’s presentation? Devin talked about how organizations have lost the ability to development and provide professional development plans. He went into detail about Transdisciplinarity- the ability to bridge the silos. Siloing is a symptom of old hierarchical structures; quite frankly, its old world thinking brought into the new world of software development. Though its great to have a specialty as you progress in your career, there is a need to generalize in other aspects of the team. Devin wrapped up his discussion with a short exercise that emphasized the need for building core skills as leaders.


Agile Transformation: It’s as Easy as Riding a Bike by Laura Smyrl

IMG_0008As I highlighted in my user story tune up: ‘Sometimes you have to go back to basics and remember where you came from’. I intend to closely work with organizations undergoing transformations, so I wanted to remember what it was like to sit in the room and have all these career-altering ideas revealed. I was not disappointed with the material or Laura’s fantastic metaphor.

Laura covered all the stages of riding a bike, from beginner to professional. She made connections between these stages to our agile journey. Her presentation emphasized the importance of ensuring our teams have the right equipment, experience, and trust. She also emphasized that the team should understand the individual roles and make sure that one person isn’t getting slammed with all the work. I also want to give a virtual ‘high five’ to Laura for finally saying what many keep wavering on: ‘Scrum teams need dedicated ScrumMasters’. ScrumMasters are like a coach in professional sports. They’re surrounded by athletes that have been playing that sport their entire life; can they go out and compete without a coach? Likely. Will they compete and WIN? Probably not. A coach provides insights and makes tweaks by constantly observing the team. A ScrumMaster doesn’t have the same direct authority of a coach, but they can make the same recommendations and tweaks to help the team.

Laura did a fantastic job taking the crowd on the journey from beginner to professional. It was an excellent reminder of where I was on my journey 2 years ago, and where I am now.


A Model For Agile Coaches And ScrumMasters To Do Great Things by Jason Tanner

I finished off my break away sessions with Jason Tanner’s model for coaches and ScrumMasters. This presentation felt very relevant to where I am in my career- 2 years a ScrumMaster and on the journey to either becoming a coach or trainer. When you commit to becoming a ScrumMaster, your trainer goes into details about the inner workings of Scrum and the team. If you have a good trainer, as I did, he/she will introduce you to the coaching aspect of the ScrumMaster. I have had the opportunity to sit as a ScrumMaster/Supervisor and solely as a ScrumMaster. From my own experience, the ScrumMaster/Supervisor was quite easy; however, I later realized that my authoritative title stunted the team from pushing back and growing. Working as a ScrumMaster for a high performing team has been a challenge, but in a good way. Jason framed what we do as ScrumMasters and coaches nicely. He first outlined the roles that we take on a daily basis: counselor, coach, partner, facilitator, etc. Next, he explained how adopting these roles for a particular scenario could prove beneficial to the team. Specifically, he laid out a pattern to follow:

Observation => Hypothesis => Design => Intervention => Reflection


For years I have been flowing through this model without really knowing it. I intend to incorporate Jason’s model into my daily routine. After going through some exercises during the presentation I realized that I need a lot of practice; but I also realized how much better I can be as a ScrumMaster and coach with this model in my arsenal.


Introducing the GROWS Method: An Anti-Agile Framework by Andy Hunt

Last, but certainly not least, we all gathered back in the main hall for Andy Hunt- one of the founders of the Agile Manifesto. Andy finished the long day off with a strong, entertaining, and very informative talk. I was slightly taken aback by his offensive on agile frameworks along with one of the bullets in his presentation- ‘Agile methods are not Agile’. His comments were a hook to explain that over the course of almost 15 years, not much has changed. Seriously, how contradictory is that? It was a point that felt like a punch in the gut, but so necessary. Andy went on to introduce the 4 pillars to GROWS: Dreyfus skill model, directed empiricism, inclusive, and self determined adaptation. As he continued on with his talk, I kept reflecting back at how stagnant agile frameworks have grown over the years. Then, I started to think about how many practitioners have introduced variety into the frameworks, and we HAVE experimented. The theme of looking at failure as a step to innovation and growth continued to resonate all the way through the final keynote.



I’ve been gushing on and on about the presenters and their material. Overall, the location, parking, food, vendors, rooms, etc were exceptional! Though its only in its second year, TriAgile feels like one of the larger, nationally established conferences. The organizers mentioned that their aim next year is to attract more out of state participants. I really do believe they will be able to achieve this. I can only imagine the stories I will hear from presenters and participants in 2016. If you’re looking for an affordable, informative conference, I highly recommend putting TriAgile on your radar.




Martin, Robert C. (2011-05-13). The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series) (Kindle Locations 602-605). Pearson Education. Kindle Edition.






ScrumMaster Beyond the Team Debrief


In a recent presentation to the Red Hat Agile Community, I prepared a talk on the ScrumMaster role outside of the team. It took several weeks to put this together; I really wanted this to make an impact and motivate the group. This topic contained some very important information, but the delivery could easily sway the intended audience to either listen or ‘shut down’. The primary objective focused on the role a ScrumMaster plays after his/her team becomes high performing. I was using my own professional anecdotes and Essential Scrum as the basis for my case. Specifically,  in Essential Scrum  Kenneth Rubin states, “Usually as the Scrum team’s need for a ScrumMaster decreases, the need for the ScrumMaster to focus on broader organizational impediments and to be a change agent throughout the organization value chain increases” (192). However, the secondary intent aimed at motivating ScrumMasters that have grown complacent in their role. The Red Hat Agile community is in its early stages, and it needs the unified effort of its ScrumMasters and practitioners to truly make a difference within the organization. After deliberating the delivery of the speech, I opted to take a more informative approach instead of my usual ‘fire and brimstone’. This approach would appeal to most in the Red Hat Community, avoid alienating anyone who might interpret the speech incorrectly, and inspire some to take the next steps in their agile careers. The following is the written version of the speech.


ScrumMaster Beyond the Team

Whether we like it or not, the ScrumMaster’s job does not end with the team. When we are certified, we are constantly bombarded about our responsibilities to the team. Our duty is to serve team first. We do Agile in Practicethis daily by coaching our teammates, seeking ways to continuously improve, protecting the team against blockers, and serving as ambassadors between the team and its customers.  Our goal is simple: Get our team to achieve high performance. Some ScrumMasters choose to stop here; serving as a ScrumMaster on a high performing team adds the temptation to grow complacent. I contend that there is much more value a ScrumMaster can provide. Though we are always dedicated to our team, we have a deeper calling to the organization and the overall agile community.


Impact on the Organization

The software development industry is riddled with organizations that practice ‘dysfunctional agile’. Yes, Scrum, Lean, Kanban, and many other frameworks are proclaimed in IT hallways, but chances are that upper management has no idea what it means. In other organizations, there exists direct or indirect resistance to any kind of transformation. In these scenarios I ask, ‘Where are the ScrumMasters!?’ Though the organization may not be practicing scrum, I consider change agents and members of the adoption team are ScrumMasters/Coaches. These organizations need involvement from their agile practitioners to properly align the organization on why they have chosen a collaborative strategy instead of how to collaborate. Essential Scrum details the roles good ScrumMasters can play in these scenarios:


A good ScrumMaster must help change minds as well. Scrum can be very disruptive to the status quo; the change that is required to be successful with Scrum can be difficult. The ScrumMaster helps others understand the need for change, the impacts of Scrum outside the Scrum team, and the broad-reaching benefits Scrum can help achieve. The ScrumMaster also ensures that effective change is occurring at all levels of the organization, enabling not only short-term success but, more importantly, the long-term benefits from using Scrum. (187)


It takes courage to accept change, but it takes almost an inhuman amount to lead it. During adoption and implementation, opportunities will arise for ScrumMasters to influence organizational change. Exercising tact while addressing areas of improvement is critical; you don’t want those listening to shut down before you even get a chance to propose a solution. We are the messengers of the good, bad, and the ugly; in order for our organizations to to trust us, we must be able to deliver it all.


While leading an agile adoption at one of my previous employers, our adoption team spent many days working with executives and management who were curious and skeptical. We worked to answer all their questions and concerns, and we took the time to research the answers when we could not. I’ll never forget how nervous the adoption team felt when we pitched adopting scrum to the IT executive team; you could’ve cut the tension with a knife. However, our ability to convey why we felt the change was necessary won them over, and we never looked back. Many of those on the adoption team eventually became ScrumMasters and Product Owners. We accepted the duties for our teams, but we knew we also served an organization about to go on a ‘rollercoaster’ journey.


The Agile Community

What good is knowledge if we don’t share it? Former Google CIO and VP of Engineering, Douglas Merrill, once said:

“Knowledge was power, back when knowledge wasn’t easily available or disseminated. If you lived in the 1600s and wanted to be a stonemason, you’d start off as a master’s apprentice. Instead of paying you, he’d teach you his trade. He could do this because he had the knowledge you couldn’t get elsewhere. He had power. You? Not so much.”

I’d like to encourage all agile professionals to communicate and collaborate by any means possible. This is not a community where knowledge hoarding is rewarded. Start a blog, write articles for printed and online magazine’s, attend local or national conferences, get your certifications, etc. The idea or tactic you used to help improve your team may help out a fellow professional. Just as we push our teams to continuously improve, we must do the same same with our own careers.


Don’t Get Comfortable

When making a very big professional decision my father gave me some excellent advice. He said, ‘A lot of times when someone feels comfortable they get lazy. When people get lazy, they can’t grow. If you’re comfortable, son, you will not push your limits. Sometimes we need to make ourselves uncomfortable in order grow.’ At the time his advice sounded so broad, but the more I reflected on it, the more I understood my direction. I made the decision that wasn’t the easiest, would surely push my limitations, and would inevitably lead to growth. It was also extremely risky, but I couldn’t let fear dominate my decision. Though frightening at first, this decision eventually led to starting this blog, writing articles, making presentations, putting user groups together, and getting involved with the agile community. It certainly wasn’t something I felt very comfortable in, but it was a series of deliberate decisions that offered growth opportunities.


The Journey

A ScrumMaster begins his/her journey as an individual that makes a commitment to to his/herself. We then join our teams and start marching towards the goal of high performance. If our teams reach Screen Shot 2015-03-27 at 1.34.15 PMhigh performance, opportunities will open to make impacts in the organization and beyond. As professionals, our organizations and the agile community cannot afford to have us sit on our certifications and knowledge. Complacency is not in the ScrumMaster dictionary… we threw it out when we made our decision.



  • Rubin, Kenneth. “ScrumMaster.” Essential Scrum. Pearson Education, 2013. 191. Print.




Scrum Master Misunderstood

The majority of the texts on Scrum describe Scrum Masters as a shepherd or protector of the team. You’ll often hear the ‘servant leader’ buzz term associated with Scrum Master. Of the three major roles in Scrum, the Scrum Master is often the most misinterpreted. I believe this stems from a failure to understand servant leadership combined with an organization’s knack for placing the wrong personnel in that role.


Servant Leadership

The term servant leader contains a very profound history. The term leaves the lips of many in organizations, but they know little of its true nature. To understand the term, lets examine its origins. The idea of the servant leader reaches as far back as fifth-century BC; during this period Lao-Tzu, the Father of Taoism, planted the seeds of the modern day definition of servant leader:

The highest type of ruler is one of whose existence the people are barely aware… The Sage is self-effacing and scanty of words. When his task is accomplished and things have been completed, all the people say, ‘We ourselves have achieved it!’

In 1970, Robert Greenleaf brought this ideology into the modern world in his paper, The Servant as a Leader. In it he states:

The servant leader is servant first… It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead… (vs. one who is leader first…) … The best test, and difficult to administer, is: Do those who served grow as persons … (and become) more likely themselves to become servants?

Organizations have not wrapped their heads around this concept. The possibility of losing control and power strikes fear into the hearts of those in leadership today. In the software development industry the command and control model is slowly crumbling, as evidenced by the increase of agile transformations across the globe. Rather than swing from one end of the spectrum to the opposite, I propose organizations find some ground near the middle.

In his book, Turn the Ship Around: A True Story of Turning Followers into Leaders, David Marquet describes an unorthodox approach he took with an underperforming crew; his model was contrary to the Navy’s traditional command and control, but he gained the trust of his superiors to try it on his crew. David implemented a system of ‘Intent Based Leadership’ that aimed at creating leaders throughout his crew. His implementation was a success, and it created a sense of ownership, accountability, and pride. In this model, a captain still exists; instead of focusing on giving orders on how to execute tasks or solve problems, the captain allows the crew to pull their training together and solve the problem as a team. The captain is there to facilitate and guide the crew/team to the solution, not provide it directly. The ultimate goal is to grow your team, so its members can excel both personally and professionally- self organization.


Who Gets to be a Scrum Master?

Welcome to the pitfall question facing most organizations today. In the face of transforming roles and job titles, organizations resort to filling Scrum Masters with traditional jobs- project managers, tech leads, architects, supervisors, etc. Based on what we discussed above, placing someone in a Scrum Master role because they can drive teams on a schedule, create beautiful technical designs, or write outstanding performance evaluations is far from the correct criteria. Recall, Scrum Masters have no true authority on a team. Electing an individual that shows strong authoritative characteristics may prove disastrous for the team and individual. Some of the desired characteristics of a Scrum Master include (add these to the lists you’ll find on the internet):

  • Introduces opportunities of growth for the team
  • Mentors the team in its practice of Scrum
  • Leads the team to solve challenges on their own
  • Rather than rely on metrics, intuitively understands the needs of the team and make adjustments where necessary

None of the above contain directive attributes- very different from command and control leadership. Most other authorities on Scrum will provide the same attributes. A good Scrum Master successfully battles the temptation to take the wheel and change course; instead, he/she is masterful (pun intended) at guiding the team to the conclusion that a change of course might be necessary. In summary, the Scrum Master embodies the visions of Lao-Tzu, Greenleaf, and Marquet. In order for a team to grow, they must take the wheel and lead.


Closing Thoughts

It will take some time before the Scrum Master role is understood by the majority. Servant leadership is a concept that is difficult to grasp in a society that glorifies the command and control model. Organizations that practice or intend to practice Scrum must carefully evaluate the criteria for Scrum Masters before blindly appointing candidates. The old leadership mold doesn’t fit in the software development industry. It may be a hard pill to swallow, but the agile frameworks, such as Scrum, cannot function healthily without it.




Marquet, L. David. Turn the Ship Around!: A True Story of Turning Followers into Leaders. New York: Portfolio, 2012. Print.

Greenleaf, Robert K. The Servant as Leader. Indianapolis, IN: Robert K. Greenleaf Center, 1991. Print.

Heskett, James. “Why Isn’t Servant Leadership More Prevalent?” Forbes. Forbes Magazine, 1 May 2013. Web. 22 Dec. 2014.