Launching this month: DFW Scrum Tech Edition

When I travel to agile events, I love telling people about our community. The agile community in Dallas is incredibly strong. In a typical month, there are at least 4 different meetup groups hosting events, and the number continues to grow. In fact, DFW Scrum is expanding itself again. Michael Jesse is organizing a new Technical Excellence special interest group, and the first event will be held on January 30, 2017.

Why a Tech Edition group? It started with reviewing the Agile Manifesto with a group of people, and there was a question about one principle in particular:

Continuous attention to technical excellence and good design enhances agility.

Inspired by the question of what is technical excellence, Michael decided to create a place to hear wisdom from various people on what defines it.

  • Is it as simple as having a continuous integration and continuous deployment?
  • Is it having the latest technology?
  • Is it defined by a standards organization?

All of these questions and more will be explored in the new Tech Edition group.


Our First DFW Scrum Lean Coffee!

LeanCoffeeLast night was a “Bring Your Own Topic” night for our group, and we used the Lean Coffee format to organize our conversations. As a group organizer, it can feel risky to not have a predetermined topic for a meetup. Will people show up? Will they have topics they are willing to share? Will people enjoy it? The answer is yes, yes, and yes.

We split into groups of 9 people. Each group setup its kanban board and brainstormed topics. Then discussions started flowing! We ran longer than usual, and I saw quite a few people exchanging contact information afterwards–signs of a highly successful meetup!

Thanks to everyone who attended for reaffirming how amazing lean coffees can be. Our community members grew closer last night through those conversations, and I look forward to more “BYOT” nights in the future.

New Organizers for DFW Scrum Dallas location

We kicked off 2016 by announcing two new organizers for the Dallas DFW Scrum meetups: Steve Fraser and Pradeepa Narayanaswamy. Both Steve and Pradeepa have been regular attendees at our meetups and were interested in getting more involved. I realized that I’d been organizing events for four years, and the new year presented a great opportunity to inject the group with new energy and ideas.

As a Senior Consultant with Improving, Steve Fraser has experience in all the Scrum Roles: Product Owner, Scrum Master, and Developer. He enjoys discovering, applying and sharing new techniques to produce customer value with elegant design, practical architecture, and wicked code. Steve is passionate about sharing his talents in software development, including automated testing at all levels from user journeys through unit testing and using specification by example to build living product documentation.

An agile coach and Professional Scrum Trainer, Pradeepa Narayanaswamy is a self-proclaimed “Agile Passionista” who strongly believes in agile values and principles. In her current role, Pradeepa works as a trainer, agile coach, and mentor to several teams and helps them succeed in delighting customers. She works with leadership teams in their transformation journeys using agile values and principles. A frequent speaker at national and international conferences, Pradeepa is passionate about and specializes in agile testing.

I am thrilled to have Steve and Pradeepa involved in coordinating topics and speakers for the group and appreciate the support they’ve provided over the last four months. You have probably seen them take over front of the room introductions each month, and I am excited to see how they continue to grow as leaders in our community.

Why Agile Teams Often Don’t Thrive


On TUE May 19, we hosted Ron Jeffries (yes the guy who has been building software longer than you have been alive) at DFW Scrum. Ron is a frequent visitor of our group and has provided unbelievable guidance and direction to my own teams in our transition to Scrum and agile development practices.

 Ron spoke to our group on “Why so many agile teams often don’t thrive”. I think someone who actually helped manufacture the “Agile Manifesto” would probably be a good source of information on helping us identify our pitfalls in adoption and progress.

 Ron specified 2 main points to this actual topic:

  1. Teams don’t know how to ship software every sprint

  2. Cultural changes necessary do not take place (like helping a team become better at shipping software each sprint)

 Ron’s points above aren’t really the meat to this topic in my opinion. I had a few people struggle with what Ron was trying to convey and I immediately came to his defense and asked “don’t you guys get it?”. Obviously not, therefore, this blog post. Ron’s message hit me right in the sweet spot and validated my fairly close alignment with his views on agile development practices (he obviously has been a big influence in my journey).

 The point? We spend so much “flipping” time (Ron would have used a different word) on making sure our Scrum Masters, Product Owners, and Organization Stakeholders are prepared for the agile journey that you know who we leave out of this preparation? You got it…THE TEAM!

 If we break Scrum down into its components, we “should” have 1 Product Owner, 1 Scrum Master, and 3-9 Development Team members. Where do you think the force lies in where we spend time in equipping the teams? That’s right, the backlog (which is important), how will the business react, will they engage, do we have the roles required, how will we estimate, how we will plan a roadmap, so on and so forth.

 Those are all important questions to ask, but you know which artifact in Scrum we have lost focus on? The actual increment. The increment is the most important artifact in Scrum. If a team can’t ship software each sprint, they can’t tell a story; thus they can’t get the trust and confidence needed to let the business people focus on the what; letting the teams focus on the how. Too often the teams retreat into a hell where they need to know everything up front because we leave no room for failure, mistake, or God forbid, a misunderstanding in the actual requirement.

 Ron started the talk with relating to why Kent Beck created XP (eXtreme Programming). Basically to protect the team. I have a similar mindset in my transitions to agile and will usually build an API translation layer of communication over the team to protect them as much as possible from the cruft the organization might place on them. Our goal? Ship software! Not time-sheets, estimations, roadmap planning, meetings; SHIPPING SOFTWARE!

 Product Development is a collaborative game. Each team has different skill sets, each human brings a particular experience and skill-set to the team. What we should focus on in our agile adoption is “do these teams have the skills necessary to refactor and work incrementally to deliver slices of software to a tested/integrated environment every sprint”?

 Most of the time, the answer is no, but we will spend all kinds of money on the process, the roles, and the PMO type communication abstraction layer to ensure our teams can be left alone. As they are left alone, they struggle greatly in the organizations deployment, branching, merging, and build strategies. Please don’t misunderstand, I truly believe a team needs to provide the level of transparency to the business and PMO group on our progress, but too often this turns into an inordinate amount of work for the team.

 Ron painted a picture about a company party. Most of the time you find people socializing and talking about business. You usually find the development team folks bunched up together talking about technology and cool patterns they learned over a hack-a-thon project. They do this because they are passionate about the technology in their job and solving problems. Let’s incubate that environment and provide more opportunities for these folks to learn more about technical practices that encourage quick delivery. Branching/Merging techniques that allow us to receive changes frequently to minimize conflicts. The nitty gritty of software development.

 Ron encourages the various groups in Scrum (Scrum, etc…) to think of ways we can foster growth in engineering practices. Let’s build more programs around the team and not just the Scrum Master / Product Owner.

When you go back and look at your teams, let’s see how much extraneous work we have around these folks that could be making them unhappy and uninspired in their quest to build innovative products. If your development environments are a large part of the problem, are we equipping the team with knowledge on how to incrementally refactor, incrementally make better paths to production, etc…?

 Back to Ron’s message, teams often don’t thrive because we don’t equip them with the knowledge and skills of how to incrementally build software. We focus on so much other activities and events in Scrum, that we tend to loose site of the most important thing, the increment. Ron is on a mission to help the Scrum Alliance and other organizations to start focusing on these types of activities that allow Developers an opportunity to show skills based on industry practices that can be learned through various techniques.

 I have an old saying in service organizations that says “if you aren’t servicing the customer directly, you better be servicing someone who is”. In Scrum, I can say “if you aren’t servicing the development team directly, you better be servicing someone who is”.

 We are in the business of shipping software, therefore, we better be the best shippers of software that we can. Are you?

January Recap: Dallas and Southlake Learn about Conflict

Conflict. What comes to mind when you think about conflict? Do you view it as a problem to solve? Something to make go away?

What if you could welcome conflict as an urge for change?

This was the subject of an amazing conversation led by Lyssa Adkins in our January meeting. In her talk, A Step-by-Step Guide to Changing Everything About Handling Conflict, Lyssa showed that if we take a few simple steps, change is possible, and we could get to the harmony on the other side of conflict. The key?  “Get insanely curious.”

To learn more about the session, you can view Lyssa’s presentation, handout, and Chris Murman’s blog post about the meetup.

Lyssa is co-founder of the Agile Coaching Institute, and ACI will be offering its 3-day Coaching Agile Teams class in Dallas March 4-6.

Role of a Project Manager in Scrum


We had a great turnout at DFW Scrum last TUE for “The Role of the Project Manager in Scrum”. Many organizations struggle with what to do with the Project Manager when they have a Scrum Team. Chris Eberhardt and myself facilitated this fascinating conversation. The reality is, there is not “standard” or “cookie-cutter” approach to the answer. Every culture, company, value system, etc… are a little different (or a lot for that matter). So we took the approach of facilitating conversation more than giving answers, because honestly; most people in the group have the answers, they just need validation if they are violating Scrum values.

The one big point that does apply to each company is that while the role itself is not described in Scrum, the responsibilities and duties still have to be done. Typically those duties and responsibilities are absorbed by the 3 roles in Scrum (Product Owner, Scrum Master, or Development Team). We also found some duties that aren’t necessarily part of Scrum, but needed by the organization to drive visibility, transparency, and coordination. Those burdens should be placed on the team and we should work together to figure those things out and who is best to serve those duties.

There are some organizations that exist where Development (the Scrum Team) is just a small piece of the overall “project”. In that case, we might have a project manager taking the metrics from the Scrum Team and providing visibility to the overall timeline for the other pieces. In Software, many of the Go To Market (GTM) activities might not involve the Scrum Team at all. As such, a Project Manager might piece together the finished software with the sales, support, finance, etc…

In other cases, perhaps a Scrum Master fulfills those duties in tandem with the Scrum Team duties. It really just depends. Whatever the case, the word “Project Manager” should not be a deterrent to doing Scrum. Scrum is very adamant about some things and does not outline a role for Project Manager, that doesn’t mean that we can’t figure out how to carry out the functions of the role in its absence (or presence). Be pragmatic and work as a team to figure out what works best. A traditional Project Manager tends to have duties and responsibilities that violate the tenants of Scrum. That is why aspects of that role are transferred to specific roles on the team.

Don’t let compliance and other “governance” terms deter you either. Those can be built into the definition of done for the team and considered in all aspects of our planning and completion. Naturally there are some governance processes that actually hinder productivity of the team, let’s be transparent about that and show the impact of the team and then have the team propose some possible solutions.

Attached is our Deck used to facilitate the discussion, the big take-away is this: “What kind of organization are you”? Each one presents benefits and challenges of Scrum.

Types of Organizations

  • All Scrum Masters (0:n)
    • No Project Managers, only Scrum Masters
    • Not the same as all Project Manager titles have been replaced by the title of Scrum Master
  • One Project Manager and One Scrum Master (1:1)
    • Every project has a Project Manager and a Scrum Master
  • One Project Manager and Several Scrum Masters (1:n)
    • Every project has a Project Manager but there are several Scrum Masters

Agile Jeopardy–Not as Easy as You’d Think

Last month we played Agile Jeopardy, and the questions and answers related directly to the Agile Manifesto. Four values and twelve principles—how bad could it be? Turns out most people don’t have them memorized, and our teams had a rough time.

Should we know the Agile Manifesto by heart? Quote it in the office? Recite it when we wake up and before we go to bed each day? Unless you’re playing Agile Jeopardy on a frequent basis with me as the judge, you probably don’t need to go to such extremes. But there is tremendous value in reviewing the Agile Manifesto periodically (a couple of times a year) and revisiting the significance of the values and principles. What does each piece contribute? What if it were written differently? Just how agile is your team?

I worry sometimes as an organizer that I’m not doing enough to serve the community’s needs, and I feared that our game of Agile Jeopardy might have been too much for some folks. Games bring out competition, and our teams were struggling to respond with just the right answer. Thankfully our teams took it in stride, and Chris Murman even wrote his own blog post on what he learned from the evening’s activity. We all need a good reminder now and then of “the basics.”