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.

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.”

Recap of Dallas’s July meeting: Overcoming the fear of Sprint Retrospective

July’s topic was posted by a community member on our meetup site, and after receiving a number of votes, we decided to make it the focus of a Wisdom of the Crowd night. What’s a Wisdom of the Crowd night? It’s one with no formal speaker or presentation—we enable our community to share their experiences and questions to generate new ideas and learning for all of us! We use an open space format to allow for deeper discussions of subtopics in smaller groups; if a member is interested in more than one subtopic or isn’t engaged in the group he’s in, he can move to another group without questions or judgment. Best of all, each group shares its findings at the end of the night with everyone, so we can all benefit from their learnings.

The meeting topic was Overcoming the fear of Sprint Retrospectives:

The sprint retrospective is by far the most underutilized and under appreciated meeting. Team members dread to go these meetings. Every Scrum Master has his own technique on how he overcame this and there is always room to grow.

We kicked off with some of the questions on our minds and split into multiple groups based on which question we wanted to explore further. The groups had rich discussions and came up with so many ideas that they used the whiteboards to capture them:

DFW Scrum - retrospectives 2 DFW Scrum - retrospectives 3DFW Scrum - retrospectives 4DFW Scrum - retrospectives

DFW Scrum – Second Quarter Summary

Here’s a recap of our meetings for the quarter:

April: Definition of Done, Chris Murman

Many companies practicing agile talk about the definition of done, but how many teams adhere to it on a sprint-by-sprint basis? Expectations that are either unmet, not communicated, or mismanaged are usually the source of our problems.

Chris presented some practical ideas on how to define “done” in your organization and didn’t stop there. He presented a bigger idea that surrounded the topic and gave everyone something to take back to their offices.

May: Using NPS Scoring at Sprint Reviews with Customers, Simon Cockayne

It’s extremely difficult to understand the link between a given user story and the money that could be saved/made by customers. But could customer happiness serve as a proxy to the actual or perceived value that the customer sees? Could we determine how happy each delivered user story made the customer?

So Simon introduced a Net Promoter Score (NPS) approach to determine how happy customers were with a delivered user story in a sprint review. NPS is based on a direct question: How likely are you to recommend our company/product/service to your friends and colleagues? The scoring for this answer is most often based on a 0 to 10 scale.

The results were wonderful:

  • customers were super keen to try something new.
  • the scores showed that they LOVED the stuff we were doing.
  • the scrum team was STOKED to see the high scores–that helped boost scrum team morale in the next sprint.
  • customers started interacting with each other as they discussed the value they perceived, lots of good spirits and good humor, to boot.

June: You Want to Use Scrum, You are Told to Use CMMI (How They can Work Together?), Neil Potter

The CMMI-DEV model is a collection of practices aimed at organizations that develop products, systems and IT solutions. The model is organized into five levels; each level defines more advanced practices to improve schedule, budget, risk and quality performance. The levels provide a road map for sustained incremental improvement.

CMMI practices can be implemented within any life cycle or methodology (such as Scrum, Waterfall, Spiral or Incremental). The benefits from using CMMI Level 2 and 3 practices are:

  • Clarify customer requirements early
  • Scope, plan, estimate and negotiate work to manage expectations and achieve commitments
  • Track progress to know project status at any time
  • Maintain defined quality standards throughout the organization and report strengths and problems to management
  • Manage versions of documents and code so that time is not wasted using incorrect versions or recreating lost versions
  • Manage and coordinate multiple teams that have cross dependencies
  • Employ engineering practices for design, implementation, verification and testing to reduce defects
  • Use defect data to understand and manage work quality throughout the project
  • Collect lessons learned and project data to systematically improve future organizational performance

For more information, view Neil’s presentation here.

Certificate of Occupancy

Image

Have you ever been in your building and noticed a “Certificate of Occupancy”? These gems enforce a safe occupancy number that are built around fire codes. How many people could realistically exit this building in the case of a fire? My question, as it relates to software development and Scrum Teams is; why don’t we use this same kind of approach to protecting the sustainable development pace for our team?

This came to me really quickly as our office is expanding. No matter what WE want to do, we are bound by the occupancy certificate stating that we can only fit X number of people in this building. If we violate that (and are caught) the consequences would be great with the city, but even greater if we did have a fire and were not able to get out. Part of Scrum’s role in our teams is to help us identify and stick to a constant and sustainable development pace (throughput). As such, we should have “certificates of occupancy” in place to help us legislate that rate. Most often however, we are constantly pressed by management or our Product Team to do more, regardless of the cost. Most teams are actually rewarded for their outstanding effort and exceeding their capacity. Don’t get me wrong, we want our Product Team to want the world and push us. But, what happens if you run your engine at 15,000 RPM for a long time? What happens when your CPU is at 100% capacity? What happens if the highway system is at 100% (or even more)? Things come to a screeching halt and permanent damage ensues.

People (like computers and engines) are not built to operate consistently at 100% capacity or more, and doing so has grave consequences for productivity in the long term. Helping a team become aware of their sustainable rate, and predicting delivery off of those metrics inherent in Scrum; help maintain that level of stability. The team has control over what to commit to and what to hold. The pressure is less because the backlog and roadmap are built with their sustainable pace in mind. Believe me, if you don’t give dates for delivery, someone will. So it might as well be the development team, armed with great historical evidence of their ability to deliver as well as planning deliveries based on those realities and accomplishments.

I am certainly not saying there isn’t times where we do come together and work extra hard to get things done. I’m just saying those times have to be throttled and well understood by everyone. In addition, we should be really good at what we do and have discipline and rigor in our processes. As we continuously improve and search for better and better ways to do things, we will be productive and increase our output within our sustainable rate.

If we wanted to have more than X people in our building, we could petition the city for a permit that would increase that number (or not). The burden of proof would be on us to indicate the value of such exercise and the safety measures we put in place to allow the increase. The point is, we just can’t arbitrarily state “we need to work harder this sprint to get Y done”. Next time it will be “Z”, “A”, and “B”. That will never go away. Put checks and balances in place to ensure when you violate the sustainable and constance pace in Scrum, that we recognize the impact of that and that we are doing it for real reasons. If you want to increase the certificate of occupancy in your backlog and sprints, do so with the team and build roadmaps based on sustainable pace. Running our engines at high RPMs should be the exception, not the rule.

The Flat Tire

20140512

In regards to Scrum, many people struggle to wrap their heads around the process. While it is a fairly simple framework with very little rules and prescription, it is very difficult to actually do; logistically speaking. Build a backlog…ok, well how do I do that? Have a sprint review…ok, well how do I do that?

What actually holds this thing together is the vision and goal of Scrum. The goal is to enable us to get / manage / expose our work in a consistent process while consistently increasing our Agile Engineering practices that will allow us to ship the most valuable software we can for our customers when we want to ship it. This implies that whatever is getting in the way of you shipping software needs to be resolved. Scrum’s goals are to actually expose all of those reasons why we can’t get our code from our developer’s machines into Production with little to no human interaction along the build, test, and deploy path.

Manual testing will eventually show you that you aren’t able to move quick enough each and every time you want to ship. Not having a good backlog before your next sprint will show you that you are very reactionary and as such aren’t able to ship valuable software each sprint. Scrum exposes those leaks and that’s a good thing, celebrate when you find an inefficiency; that is something that we can all fix and improve.

One of my close colleagues in the industry has always said that Scrum is like a syringe that injects Agility into the organization. I love that analogy; I have also thought of many myself. Scrum is like going to the tire repair center. If you suspect a leak in your tire, a lot of the times, you just don’t know where it is coming from. We take it to the professionals as they can expose the leak with a tried and true technique. Take the tire off, soak it in some soapy water, and voila’ your leak appears (or maybe several leaks appear). Now, we can actually fix those leaks and get the car back on the road. What if, we found those leaks, and simply just put the tire back on the car and said “yes, there are leaks, we just don’t have time to fix them now”. At that point, you would likely drive off and continue to waste time by putting air in your tires; only to have it leak out later. Worse, you could be left stranded on the side of the road because of a flat. The right thing to do is to stop down, fix the leak, and then move on.

Scrum exposes those leaks. We the people, still have to fix our problems. No one thing or process can fix our problems, we humans have to dig in and find out the best way to solve the problem. Scrum is that agreement between the team to react to things in an empirical way, not a planned/predictive way. Take the time to take the tire off the wheel, soak it in water, find the leaks, and fix them. Some leaks are so big that we have to replace the tire. That’s ok too, celebrate that we learned of that problem. Our goal is to ship valuable-quality software when we want to and leaks prevent that from happening. Fix the leaks.

Learning to be a better Facilitator and Coach

Transitioning to agile requires people to work differently and making the transition to become a great Scrum Master or Agile Coach can be difficult.  Attending a Scrum Master class is the beginning of the journey for many.  For those who wish to further their journey and deepen their skills, the Agile Coaching Institute offers intermediate level classes.
I am SUPER-EXCITED to share that Lyssa Adkins and Michael Spayd from the Agile Coaching Institute will be coming to Dallas the week of June 9th offering two of their classes: the 2-day Agile Facilitator and the 3-day Coaching Agile Teams.  You can sign up for one class or both, and registration is online at http://www.agilecoachinginstitute.com/class-schedule/ 
This is an incredible learning opportunity for agile practitioners, and I look forward to attending the classes myself.  The Agile Coaching Institute does offer certifications, which are explained in this video:

About the Agile Facilitator class:
The Agile Facilitator is for experienced Agilists who wish to dramatically increase their facilitation skills in general, especially as applied to Agile ceremonies, collaborative events and other team “moments of truth.” The workshop will focus on professional facilitation skills and techniques as applied specifically within the Agile context.  While mastering facilitation skills in the Agile context will require both time and practice, our class will allow you to:
  • Gain an in-depth and practical understanding of a wide array of techniques practiced by professional facilitators.
  • Understand and practice the art of collaborative meeting design, including the importance of smart preparation that will reduce overall cost and increase the effectiveness of your meetings.
  • Practice techniques for skillfully facilitating core Agile meetings and ceremonies with playfulness and a collaborative spirit, while still focused on key deliverables.
  • Gain rich, well-delivered feedback on your growing facilitation skills
  • Give you ideas for designing meetings in which the team interacts with the team so they can do the heavy-lifting.
  • Understand how to address some of the dysfunctional behaviors you see preventing your team from achieving maximum success.
  • Learn how to define, discuss, and ACHIEVE consensus with the team for faster and better decision making.
  • Come away with your own facilitator self-development plan.
About the Coaching Agile Teams class:
Coaching Agile Teams 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. Further, the class covers basics of team dynamics, team startup/reset, the individual change cycle, helping people through agile role transitions, and working with team conflict. The course is highly interactive and experiential. While mastering agile coaching skills will require both time and practice, our class will allow you to:
  • Understand and utilize the four key Skill Areas and four Knowledge Areas applied by the best agile coaches (ACI’s Agile Coaching Competency Framework)
  • Practice techniques for deep listening and asking essential, powerful questions.
  • Practice the distinction between coaching and mentoring and know when to apply each most successfully.
  • Observe a live, professional coaching demo on a situation in the agile context.
  • Understand how to address some of the dysfunctional approaches to conflict  team’s sometimes develop.
  • Understand a model for human change and a method for working with such change
  • You’ll walk away from the course with your personal coaching improvement backlog – a tangible plan you can use to thoughtfully improve your coaching when you’re back on the job.