backlog refinement Blogpost scrum scrummaster

The Backlog Refinement Sweetspot


I published this almost two years in a separate blog. I just started with a new company, and I have been working with several folks who are not too familiar with Scrum and some of the finer details around the events. I’m republishing this article with a few edits here and there. I hope it helps some teams that might be struggling with their Refinement sessions.

Setting the Stage

If there’s one ceremony that is very susceptible to ‘going off the rails’, it is backlog refinement. The very nature of the meeting invites the temptation to dive into more detail than necessary. This is expected; as a former software engineer, my inquisitive nature often gets the best of me. Drawing the line between ‘valuable refinement discussion’ and ‘getting lost in the weeds’ is a common challenge. There are a number of techniques a team can use to refocus including: time boxing, strict facilitation, limiting non-essential participants, etc. A few months ago, my colleague introduced me to a teaching point that we felt would help our teams take control of their Backlog Refinement sessions. Rather than tell the team that they’re going into too much detail, we offered them a technique to help them self-diagnose. My preferred moment to coach this strategy is at the beginning of the refinement session. At the beginning of the session, I like to remind the team the true intent behind backlog refinement: ‘To acquire just enough information on a story to size, so that the Product Owner can clearly review and prioritize it compared to other backlog items’. The emphasis is strongly placed on ‘just enough’. Development Teams may insist that they have to cover all the details in refinement; remind them that the implementation details should be left for Sprint Planning or story kickoff sessions. The Scrum Master should do his/her best Aaron Rogers impression (sans mustache):

After setting the tone for the session, the graph below is introduced. It represents the qualitative journey a team takes when discussing stories:

Graph Walkthrough

Approaching Point A (Brand New Story)

As a team discusses a new story, they know very little about the business value and/or the technical details. The story serves as the spark for the discussion; the team and Product Owner start to dive into the narrative to identify what value the story is attempting to deliver.

Point A (The Aha Moment)

By this point, the Product Owner has described the business value of the story and why he/she is considering this for prioritization. Now, the team is starting to jump into the conversation and the Product Owner is simply facilitating. As an observer, you can almost ‘feel’ the electricity in the room.

Between A and B (Enjoy the Ride)

Welcome to the Backlog Refinement sweet spot! The story that was hard to discern in the fog, has emerged. The solution to the problem isn’t fully outlined, but enough is known where all members have an idea how much effort it will take. Now, the team is expanding the acceptance criteria, considering system dependencies, or maybe covering very high level design. But when does the team know when it is covered ‘just enough’?

Point B and Beyond (Diminishing Returns)

How do we know when our session has turned from productive fact finding to detail driven design? As a non-technical observer, it is difficult to ascertain when the conversations move away from important story refinement. Beyond this point, the team can still acquire valuable information, but it is not as impactful. When I’m observing or facilitating, I don’t want to interrupt a potentially groundbreaking discussion, but I also don’t want to get too far ahead of ourselves. This where I like to tie the illustration to a simple question.

“So, Where are We?”

With teams that traditionally venture beyond the sweet spot, I like to introduce the graph prior to a refinement session and explain why I’d like them to consider it. The emphasis for the session is to land somewhere between A and B- where we have just enough information. I encourage the team to be cognizant of where they are in the discussion.

  • Are we still learning about the story?
  • Are team members coming up with pertinent ideas that are furthering the understanding?
  • Are the acceptance criteria being updated?


  • Has the discussion started to die down?
  • Are we discussing corner case scenarios?
  • Has the conversation started to dive into full blown technical design?

If a team member feels that they’ve ventured into the latter, I’ve proposed one simple tactic: Refer back to the graph and ask, “Where are we on the refinement curve?” This quick question gives the team an opportunity to reflect on where they are in the conversation. If it is still valuable, then they’ll call it out and continue. If they feel they’ve ventured too far, they’re now aware. Anyone can make this check- beware of stepping on any ongoing conversations though. The goal is to improve the team’s self-awareness. They should be able to get a feel when they’ve strayed.

My Experience

I’ve tried this with a variety of teams with reasonable success. It is definitely not a magic bullet if your refinement sessions are sputtering. However, it is a solid non-traditional strategy. I enjoy giving teams these tools to solve their own challenges rather than telling them they’re doing it wrong. There’s much more potential for improvement when a team can self-correct, rather than relying on someone to make the corrections for them.

Blogpost Leadership scrum

Ken Schwaber on the ScrumMaster

“The ScrumMaster is a leader, not a manager”

– Ken Schwaber, Agile Project Management with Scrum


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.