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.

Special Agile Events Coming to Dallas in March 2015

We’ve highlighted some upcoming agile events during our monthly meetups, and I know it can be difficult to remember the details later (especially the URLs).  Information about two special events coming to Dallas in March 2015 is below:

The first event is the Coaching Agile Teams class by the Agile Coaching Institute on March 4-6, 2015.  This three-day class is for experienced Agilists who wish to dramatically increase their overall agile coaching skills, including in the areas of Teaching, Mentoring, Facilitation, and Professional Coaching.  Results in a class certification in Agile Coaching by the International Consortium for Agile within their Agile Facilitation and Coaching track.  Counts as 21 SEUs by the Scrum Alliance.

The second event is Scrum Day for Professionals by Scrum.org on March 27, 2015 at the Addison Conference Center.  Join Scrum.org’s world-class experts for a day of face-to-face learning!  Participate in advanced panel discussions and sessions with experts who’ve been there.  Gain insights into agile practices you can employ immediately, and network with other professionals over complimentary breakfast, lunch, and snacks.  If you have any of the Scrum.org’s Scrum certifications (PSM, PSPO, PSD), you can receive an extra $150.00 discount on your registration fee.

 

December Dallas Recap: Scrum and the 3 Pillars

To wrap up 2014, we reviewed scrum and the three pillars of empiricism—a topic that could be considered foundational to deeply understanding the framework and one that is often overlooked in favor of focusing on practices.  From the Scrum Guide:

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known.

In order to do better today than we did yesterday, we need to not only learn new things but also remember what we’ve learned before. This topic offered a bit of something new and something old for our attendees.

DFW Scrummer Andy McKnight presented the night’s topic and included a group game: without use of a thermostat, determine what types of things you would take into consideration to maintain the temperature in a 20×20 room. How would you inspect and adapt to maintain the temperature? The ideas from the group were quite creative!

A thermostat inspects and adapts, and it provides transparency. These are the three pillars of empiricism that are the basis of scrum.  According to Ken Schwaber and David Starr,

Opacity when inspecting an Increment is like covering a thermostat with a cold, wet washcloth. The thermostat doesn’t have the correct understanding of the actual room temperature, and would incorrectly initiate heating when it should be cooling.

 

Without transparent Increments, the stakeholders don’t have a correct understanding of what is actually happening, and may incorrectly take actions that don’t make sense.

 

In short, without full transparency, the ability of the teams to inspect and adapt effectively is lost.

Without empiricism, we run the risk of this:

I prefer meeting with fellow DFW Scrummers to enjoy this:

Thank you to everyone who attended our meetups in 2014. This year saw the expansion of our group with the addition of a second location, and more of our members helped by facilitating small group discussions, answering questions and sharing experiences, and presenting topics. We are blessed to be part of such a strong and thriving agile community, and we look forward to seeing you in 2015!

November Dallas Recap: Relative Sizing and Estimation

Are you familiar with relative sizing and estimation? They are are generally accepted Scrum practices. Even though many Scrum teams do some form of estimation, it can be a confusing topic to explain. Why are these oft-used practices so difficult, and how can we broach the subjects with our own teams to ensure we’re on the same page? To help us answer these questions, our own Ty Crockett gave a brief presentation and then opened the topic further for small group discussions.

Ty helped us start at the beginning: why do we estimate? There are many possible reasons why estimates may be wanted. Our stakeholders want estimates for forecasting purposes. We can use estimates as an indicator for risk and to highlight where we need to have further conversations. Perhaps most importantly, having team members estimate work can gauge whether or not we have a shared understanding of the work. And in some cases, we simply want an idea of how much effort something is to get an idea of how much we can do.

With that in mind, we moved onto the next challenging question: what is a story point? The short answer is that it’s the unit of measure commonly used for relative sizing. Story points allow us to compare items to one another to determine their size. Hours are problematic because the focus is often on precision rather than accuracy, and team members might complete the same tasks at different rates—how could a team ever agree on estimates in hours? As Mike Cohn notes, “story points are helpful because they allow team members who perform at different speeds to communicate and estimate collaboratively.” When estimating in story points, a team might consider complexity, effort, annoyance, or skill; the important thing is that the team members agree on what factors to consider when estimating.

Now that we know how big things are relative to one another, we can look at how much a team can get done over time. We can track how much the team is getting done each sprint, look at velocity trends, and forecast how long it will take to complete work in the product backlog. And we can do it with an easy-to-understand graph!

Those are the basics of relative sizing and estimation, and Ty provided more depth to the topic during our meeting. His slides are available on the DFW Scrum meetup site. Ty is an active member of DFW Scrum and is happy to talk more about relative sizing and estimation.

October Dallas Recap: Don’t DO Agile…

We kicked off the fourth quarter in Dallas with an entertaining and enlightening presentation by Bob Schatz on “being” agile rather than “doing” agile. Bob is a long-time Certified Scrum Trainer, and his passion for creating motivated teams was clear. Applying agile practices won’t automagically make your projects successful or your customers happier, but being more agile by using improved techniques can make a big difference. The truth is you have to have the right people on your teams, and expectations of employees have changed. Gone are the days of wanting people to do only as they are told; we want employees who will treat work as a practice. We want professionals who practice with purpose. Being professional is not the same as being obedient. We need people who will seek new ideas and not just answers.

We want to create a winning culture that motivates people for better and create empathy for customers. Let’s design the organization to deliver and satisfy the customer. When do you want to find out customers don’t want your software? Find out earlier. We want to focus on quality in everything we do, which means always looking for a better way. By changing our mindsets to be more agile, we can deliver better.

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

September Dallas Recap: Integrating UX and Agile

This month was focused on one of the challenges commonly faced in agile adoptions: how to integrate UX and agile. We saw many new faces at our meeting, which confirmed what a hot topic this is. David Belcher, Director of User Experience at Improving Enterprises, shared his personal experiences and answered questions throughout the evening. As he reviewed the Good, the Bad, and the Ugly of uniting the UX processes with Agile, it was clear that there is no simple answer.

If you missed the session and want to know ideas for a successful UX and agile merger for a project team, there is a video of this same presentation available online from the AgileDotNext Houston conference (thanks to usergroup.tv):

About David Belcher: 
David is a Consultant and Director of User Experience at Improving Enterprises. He has over 10 years of experience doing UX and most of that time has been working on Agile teams. UX is David’s passion and enjoys doing everything from user research, visual design and even gets into front-end development. When he is not working enjoys life and tries to live it the fullest by traveling and learning new things.