Cultures Embracing: Agile, UX, & Business
While there is already numerous articles on these topics, I wanted to share my perspectives and experience especially from the viewpoint as a UX practitioner and the intersection of Business, Agile, and UX.
“Great leaders are those who trust their gut. They are those who understand the art before the science. They win hearts before minds.”
~Simon Sinek, author of Start with Why
Many businesses today still operate using “business theories left over from the 1980’s and 1990's” stated Simon Sinek, author of Start With Why and Together is Better, at a Creative Mornings San Diego event in October 2016. Businesses focus on short-term planning for their vision and direction, rather than planning for the long-term. This seems to be especially true when a publicly traded companies make decisions based upon their daily stock price, or quarterly earnings reports. As Sinek went on to describe in his speech, “Businesses today destroy their own corporate culture …it’s like prioritizing the needs of the fans over the needs of the team, and wanting to grow a great team.” Employees need to have a positive sense of purpose and impact. Employees today are demanding an increased level of transparency from their employers.
“Businesses today destroy their own corporate culture…”
At the 2016 O’Reilly Next:Economy summit in San Francisco, host Tim O’Reilly opened the event quoting Benjamin Franklin: “We must hang together or we’ll hang separately.” Prith Banerjee, Executive Vice President and Chief Technology Officer at Schneider Electric, also a speaker at the summit described “the old model was where managers were thinkers and employees were doers …in the digital world, this is being wiped out.” Managers need to set the vision and direction. Then they serve as a coach to keep the teams in their charge. Employees need to be empowered to determine how to achieve the vision and direction set by their managers, while staying aligned in a collaborative manner.
“…the old model was where managers were thinkers and employees were doers …in the digital world, this is being wiped out.”
Jeffery Smith, Chief Information Officer at IBM, also spoke at the 2016 O’Reilly Next:Economy summit in October, during a segment titled “How Jeff Smith built an Agile Culture at IBM.” Smith explained how he helped to transition the company culture from approximately 40,000 developers to 4,000 squads, each consisting of 10 developers. “Small squads, loosely coupled and tightly aligned …which led to the lowest attrition rates,” Smith stated. To keep the teams tightly aligned, management needed to regularly provide clarity of purpose to all the teams. He went on to describe, in order to increase aspirations their approach was: “We’re not going to tell you how to do it. We’re here to support you. We’ll give you the tools to solve it.” In other words, the role of leadership shifted to creating purpose and good work environment. Then accountability and responsibility was established for each of the squads to solve problems and for cross-functional team members to connect-the-dots across the squads. Smith also mentioned this concept was inspired by Spotify’s Engineering Culture (to note, Spotify has published a few excellent videos describing their philosophy and cultural approach). To further increase communication and leadership, Smith and his colleagues established 8–10 people to a Squad, with multiple squads forming a Tribe, multiple tribes to creating a Domain. Additionally, Guilds and Chapters where created as communities spanning across a tribes. Guilds were empowered to self-discipline and make decisions.
“Small squads, loosely coupled and tightly aligned …which led to the lowest attrition rates”
As examples from Jeffery Smith depicted, the agile methodology can be embraced for a single team, or going more pervasive, embraced as an enterprise culture. Let’s establish a common description of the agile methodology. From my personal past experience, correctly facilitating the team to follow the first five elements of the methodology (“Vision,” “Product Backlog,” “Backlog Grooming,” “Iteration Planning,” & “Iteration”) are key to the entire success of implementing agile methodology.
AGILE
The “Manifesto for Agile Software Development” (www.agilemanifesto.org) states the following 4 tenets as:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Roles
- Stakerholder — an individual who has requested the project, is funding the project, or who has some other vested-interest in the success of the project.
- Scrum Product Owner (PO) — an individual primarily responsible for the product vision, as well as making decisions to maximize the return on investment (ROI) of the project. This person needs to constantly re-prioritize the Product Backlog (defined below), by working with Stakeholders to adjust priorities of new capabilities and enhancement requests. Additionally, they adjust any long-term expectations, such as product release plans.
- Scrum Master (SM) — an individual who serves as the coach for the Scrum Team Members, to primarily facilitate the Scrum process and helps resolve impediments. This person is not a coordinator and has no management authority over the team (a person with direct managerial authority over the team, is by definition not the team’s Scrum Master).
- Scrum Team Members — a cross-functional, self-organizing group of individuals (such as business analysts, developers, designers, etc.). Each of these individuals are focused on the tasks of the team and do not have additional externally assigned roles.
Vision
The Product Owner (PO) works with stakeholders to craft a vision.
Product Backlog
An itemized list of all the requested work for the project, a.k.a. the requirements list. Each item within the list is referred a Product Backlog Item (PBI). Information captured as part of the PBI should be written to describe the value benefit to the end-user of the product, known as a “User Story” or “Epic.” For example, here is a mad-lib format: As a ____{persona }____, I want to ____{action / task to perform}____, so that I may ____{value-add / benefit}____. If some User Stories and Epics are complex, the Product Owner (PO) should re-write the User Story to decompose into the smallest description possible. The Product Backlog list should be complied, sequentially ordered, and prioritized regularly by the PO. A schedule or timeline should not be associated to either the Product Backlog or any PBI.
Backlog Grooming
At the start of each iteration, re-prioritize items within the Backlog to adapt to changes in business needs and/or scope. Backlog Grooming meeting should occur regularly, such as once per week, to serve as a planning activity for the next iteration. Each item within the Backlog should already be drafted as a User Story prior to starting the Backlog Grooming. During the Backlog Grooming meeting, tasks and sub-tasks can be created to further identify the work that may needed to be performed, such as database modifications, API endpoints, and front-end development. Story Points (a.k.a. Planning Poker) is a technique Scrum Team Members can use to determine both the perceived level of difficulty and the perceived volume of work, to achieve the given User Story. Story Point values should not be used as an equivalent measure of estimated hours, but rather as a measure of level of effort relative to the other User Stories. It’s recommended to use the Fibonacci number scale for the Story Points, then larger values indicated an increased magnitude in effort. The goal of this technique is to enable the Scrum Team Members to gain an understanding of each other’s work for the Iteration.
Iteration Planning
During the Iteration Planning, User Stories from the prioritized Product Backlog are selected by Scrum Team Members to commit to achieving by the end of the Iteration time-duration. If needed, User Stories can be deconstructed into smaller actionable tasks and sub-tasks. To aid the process of deconstructing complex User Stories, a technique called User Story Mapping can be used. The sum of the Story Points values can provide an estimate of the team’s potential bandwidth thru-put for the Iteration (also referred to as “Iteration Velocity”). Looking back at past Iterations, actual velocities can be used to compare to the estimated Iteration Velocity, to inform the team’s achieved bandwidth thru-put.
Iteration
Throughout the duration of the Iteration, progress towards completion is tracked for User Stories, as well as for their related tasks and sub-tasks. Some recommended categories for tracking progress are:
- Committed — the team has committed to achieving this user story or task during the current Iteration, however work on this item has not yet started.
- In-Progress — a team member has begun work on this item
- In-Testing — a team member is reviewing work completed compared to the information described within the User Story.
- Completed— this item is 100% developed, tested, and ready for deployment.
It is strongly encouraged to have a visual display of all User Stories, tasks, and sub-tasks which all Scrum Team Members can access. This will help communication for all team members to stay informed on their collective progress. Some teams choose to color coding elements to assist in the visual display, such as: Planned user stories (Green), Tasks/sub-tasks (White), Unplanned user stories (Yellow), Bugs (Blue), Impediments (Red). Also as part of the Iteration, the team’s actual velocity should be measured during an Iteration, as well as Iteration-to-Iteration.
Potentially Shippable Product “Increment”
At the end of each Iteration, the Product Owner can choose to “ship” the incremental changes/improvements of the product, or to wait to ship after a future iteration. This decreases pressure for the team rushing to have something to “ship” at the end of each iteration, inversely it should enable the team to focus on quality.
Iteration Review
The Iteration Review is a scheduled, informal meeting for the Scrum Team Members to show what they accomplished during the Iteration. Attendees of the meeting should include the Product Owner, the Scrum Team Members, the ScrumMaster, as well as, if relevant, management, customers and developers from other projects.
Iteration Retrospective
This one-hour meeting should be regularly scheduled for only the ScrumMaster and Scrum Team Members at the end of each Iteration. The primary purpose of this meeting is to look for opportunities to further improve the team. A recommendation is for the ScrumMaster to facilitate the conversation by asking each of the team members to identify specific things that the team should: a) Start doing, b) Stop doing, and c) Continue doing. Then the team can vote on specific things to focus attention on during the next sprint. Additionally, the team can also reflect on the list of things selected for attention from the prior Iteration Retrospective.
…and repeat each of these for the next iteration.
UX, ITERATIONS, and SPRINT 0
User experience practices, in my opinion when performed to the best of their strengths, naturally embrace the Agile Manifesto philosophy. Collaboration with individuals and interactions with the Product Owner and Scrum Team members to brainstorm together, over an emphasis on specific design processes and tools. Working in a nimble manner to help the team iteratively explore concepts for the product (such as creating rapid prototypes), over comprehensive documentation of a complete design specification or pixel perfect mockup composition. Having empathy for the people who will use the product is at the core heart of UX, hence the need to having varying levels of customer collaboration. One common technique to achieve this is by soliciting statistical and anecdotal feedback from customers of what is currently working well and not working well. Another imperative technique is to conduct usability research studies with actual customers to validate design and implementation decisions. Which leads perfectly to the last item of the manifesto, responding to change over following a plan. People evolve over time, just as customer expectations evolve over time, therefore products need to evolve over time. As previously stated, UX practitioners need to be nimble in the manner of both how they work as well as the output of their work, to iteratively receive feedback on their designs and adapt to evolving business needs.
On a few occasions in the past, I’ve been asked by colleagues “should there be a Sprint 0 for design efforts?” Personally, I’ve gone back and forth on my stance to this topic. As I reflect back, there doesn’t seem to be a right or wrong answer to having a Sprint 0. In true agile methodology of having self-organizing teams, it should be up to the team to try both models as experiments over the span of two or three iterations to see which works best for the team. I’ve been a member of scrum teams that have successfully used both models, having and not having a Sprint 0. In the case when a Sprint 0 was used, User Stories were drafted, added to the Backlog, and marked as “Design.” When Backlog Grooming is performed, the UX practitioner should use the same backlog grooming techniques to ensure work is being performed in the order of the business priorities. I’ve observed numerous situations when a single User Story was a large level of effort for a developer but a small level of effort for a designer, and equally the inverse, a small level of effort for a developer but a large level of effort for a designer. In following agile methodology, this is a perfect example of empowering the Scrum Team Members to gain a deeper understanding of each other’s work.
“We’re not going to tell you how to do it. We’re here to support you. We’ll give you the tools to solve it.”
Many teams have found phenomenal success with the right blend of business culture, agile methodologies, and user experience philosophies. From the design discipline in both industry and academia, there should be more individuals who have at least a basic understanding of business and programming (while their area of expertise is still focused on design). I’m hopeful that this article will also help some students and professors to see, from my perspective, the current trajectory of industry trends. Speaking to college students is a start, as such I’m scheduled to do so later this month with my alma mater, Purdue University.
“…transparency of what is needed.”
Penny Pritzker, 38th United States Secretary of Commerce, spoke at the same O’Reilly Next:Economy summit previously mentioned. She stated “we need local partners to address the skills gap… for business leaders to come together with K-12, Universities and social services — help to bridge the gap …[to increase] transparency of what is needed.”
Here are some tools, and now it’s up to you on how you choose to use them. To quote Simon Sinek, “We’re better together. Show up with empathy.”
Looking for UX assistance on projects alongside your agile teams? Learn more about the user experience and interactive strategy consulting services of Garofalo Studios: www.garofalostudios.com/consulting and our UX design help as an affordable subscription plan service: www.uxsubscription.com
Frank Garofalo is a Certified ScrumMaster and Certified Scrum Product Owner from the Scrum Alliance (at the time this article was published).
