Visually, they can be high, medium, or even low fidelity. The value here is not so much the visual polish, but rather the ability to simulate workflow and to observe how users interact with your designs.
Highlight (blue) - Making Sense of the Research: A Team Activity > Location 2003
Coded prototypes
Highlight (yellow) - Making Sense of the Research: A Team Activity > Location 2003
Coded prototypes are useful because they have the best ability to deliver high fidelity in terms of functionality. This makes for the closest- to- real simulation that you can put in front of your users.
Highlight (yellow) - Making Sense of the Research: A Team Activity > Location 2007
But because the feedback you gain is based on such a close simulation, you can treat that feedback as more authoritative than the feedback you gain from other simulations.
Highlight (blue) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2010
Monitoring Techniques for Continuous and Collaborative Discovery
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2011
In the preceding discussions, we looked at ways to use qualitative research on a regular basis to evaluate your hypotheses. However, as soon as you launch your product or feature, your customers will begin giving you constant feedback— and not only on your product.
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2015
They will tell you about themselves, about the market, about the competition. This insight is invaluable— and it comes in to your organization from every corner.
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2018
Figure 6- 7. Customers can provide feedback through many channels
Highlight (blue) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2020
Customer Service
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2020
Customer support agents talk to more customers on a daily basis than you will talk to over the course of an entire project. There are multiple ways to harness their knowledge:
Highlight (pink) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2023
Reach out to them and ask them what they’re hearing from customers about the sections of the product on which you’re working.
Highlight (pink) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2024
Hold regular monthly meetings with them to understand the trends. What do customers love this month? What do they hate?
Highlight (pink) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2025
Tap into their deep product knowledge to learn how they would solve the challenges your team is working on. Include them in design sessions and design reviews.
Highlight (pink) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2026
Incorporate your hypotheses into their call scripts— one of the cheapest ways to test your ideas is to suggest it as a fix to customers calling in with a relevant complaint.
Note - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2027
Smart and efficient!
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2027
In the mid- 2000s, Jeff ran the UX team at a mid- sized tech company in Portland, Oregon. One of the ways that team prioritized the work they did was by regularly checking the pulse of the customer base.
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2029
Each month Customer Service would provide the UX team with the top 10 things customers were complaining about.
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2031
At the end of the month, the next conversation with Customer Service gave the team a clear indication of whether or not their efforts were bearing fruit. If the issue was not receding in the top- 10 list, the solutions had not worked.
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2033
This approach generated an additional benefit. The Customer Service team realized there was someone listening to their insights and began proactively sharing customer feedback above and beyond the monthly meeting.
Highlight (blue) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2036
On- Site Feedback Surveys
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2036
Set up a feedback mechanism in your product with which customers can send you their thoughts regularly. Here are a few options:
Highlight (pink) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2039
Simple email forms
Highlight (pink) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2039
Customer support forums
Highlight (pink) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2039
Third- party community sites
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2040
You can repurpose these tools for research by doing things like the following:
Highlight (pink) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2040
Counting how many inbound emails you’re getting from a particular section of the site
Highlight (pink) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2041
Participating in online discussions and testing some of your hypotheses
Highlight (pink) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2041
Exploring community sites to discover and recruit hard- to- find types of users
Highlight (blue) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2044
Search logs
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2044
Search terms are clear indicators of what customers are seeking on your site. Search patterns indicate what they’re finding and what they’re not finding. Repeated queries with slight variations show a user’s challenge in finding certain information.
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2048
One way to use search logs for MVP validation is to launch a test page for the feature you’re planning. Following the search, logs will inform you as to whether the test content (or feature) on that page is meeting the user’s needs. If users continue to search on variations of that content, your experiment has failed.
Highlight (blue) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2051
Site usage analytics
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2051
Site usage logs and analytics packages— especially funnel analyses— show how customers are using the site, where they’re dropping off, and how they try to manipulate the product to do the things they need or expect it to do. Understanding these reports provides real- world context for the decisions the team needs to make.
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2057
If you’re just starting to build a product, build usage analytics into it from day one. Third- party products like Kiss Metrics and MixPanel make it easy and inexpensive to implement this functionality, and provide invaluable information to support continuous learning.
Highlight (blue) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2060
A/ B testing
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2061
A/ B testing is a technique, originally developed by marketers, to gauge which of two (or more) relatively similar concepts achieve the defined goal more effectively.
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2063
When applied in the Lean UX framework, A/ B testing becomes a powerful tool to determine the validity of your hypotheses. Applying A/ B testing is relatively straightforward after your ideas evolve into working code. Here’s how it works:
Highlight (pink) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2065
Take the proposed solution and release it to your audience. However, instead of letting every customer see it, release it only to a small subset of users.
Highlight (pink) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2066
Measure the performance of your solution for that audience. Compare it to the other group (your control cohort) and note the differences.
Highlight (pink) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2067
Did your new idea move the needle in the right direction? If it did, you’ve got a winning idea.
Highlight (pink) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2068
If not, you’ve got an audience of customers that might make good targets for further research. What did they think of the new experience? Would it make sense to reach out to them for some qualitative research?
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2070
The tools for A/ B testing are widely available and can be inexpensive. There are third- party commercial tools like Optimizely. There also are open source A/ B testing frameworks available for every major platform.
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2071
Regardless of the tools you choose, the trick is to make sure the changes you’re making are small enough and the population you select large enough that any change in behavior can be attributed with confidence to the change you’ve made.
Highlight (yellow) - Monitoring Techniques for Continuous and Collaborative Discovery > Location 2073
If you change too many things, any behavioral change cannot be directly attributed to your exact hypothesis.
Highlight (yellow) - Wrapping Up > Location 2077
In this chapter, we covered many ways to validate your hypotheses. We looked at collaborative discovery and continuous learning techniques. We discussed how to build a weekly Lean testing process and covered what you should test and what to expect from those tests. We looked at ways to monitor your customer experience in a Lean UX context and we touched on the power of A/ B testing.
III. Lean UX in Your Organization
Highlight (yellow) - Wrapping Up > Location 2087
Integrating design into Agile development is never easy. Sometimes, it causes a lot of pain and heartache. Jeff learned that first- hand when he was at TheLadders. After spending some time trying to integrate UX work with an Agile process, Jeff was feeling pretty good— until one morning when his UX team delivered the diagram shown in Figure III- 1.
Highlight (yellow) - Wrapping Up > Location 2089
This diagram visualized all of the challenges the team was facing as they tried to integrate its practice into the Agile environment. It served, initially, as a large slice of humble pie. Ultimately, though, it provided the beginning of conversations that helped Jeff, his UX team, and the rest of TheLadders’ product development staff build an integrated, collaborative practice.
Highlight (yellow) - Wrapping Up > Location 2093
Figure III- 1. The UX team at TheLadders expressed their feelings about our Agile/ UX integration efforts
Highlight (yellow) - Wrapping Up > Location 2099
We’ve built up a body of knowledge over the past five years that has given us a clear sense of what needs to happen— at the team and at the organization level— for Lean UX to succeed. This is the focus of Part III.
Highlight (pink) - Wrapping Up > Location 2101
Chapter 7 discusses how Lean UX fits into an Agile environment.
Highlight (pink) - Wrapping Up > Location 2102
Chapter 8 digs into the specific organizational changes that you need to make to support this way of working. It’s not just software developers and designers who need to find a way to work together: your entire product development engine is going to need to change if you want to create a truly Agile organization.
Highlight (pink) - Wrapping Up > Location 2105
Chapter 9 presents a set of case studies that showcase how these tactics and organizational shifts have succeeded at a variety of companies.
7. Integrating Lean UX and Agile
Highlight (yellow) - Wrapping Up > Location 2108
Agile methods are mainstream now. At the same time, thanks to the huge success of products like Amazon’s Kindle and Apple’s iPhone, so is User Experience (UX) design. But making Agile work with UX continues to be a challenge for many companies. In this chapter, we review how Lean UX methods can fit within the most popular flavor of Agile— Scrum— and discuss how blending Lean UX and Agile can create a more productive team and a more collaborative process. Here’s what this chapter covers:
Highlight (pink) - Wrapping Up > Location 2113
Definition of terms
Highlight (pink) - Wrapping Up > Location 2115
Staggered sprints
Highlight (pink) - Wrapping Up > Location 2117
Sprint zero and design sprints
Highlight (pink) - Wrapping Up > Location 2118
Dual- track Agile
Highlight (pink) - Wrapping Up > Location 2119
Listening to Scrum’s rhythms
Highlight (pink) - Wrapping Up > Location 2121
Participation
Highlight (pink) - Wrapping Up > Location 2122
Design is a team sport
Highlight (pink) - Wrapping Up > Location 2124
Coordinating multiple Lean UX teams
Highlight (pink) - Wrapping Up > Location 2125
Managing up and out
Highlight (blue) - Some Definitions > Location 2127
Some Definitions
Highlight (yellow) - Some Definitions > Location 2128
Agile processes like Scrum use many proprietary terms. Over time, many of these terms have taken on a life of their own.
Highlight (pink) - Some Definitions > Location 2131
Scrum
Highlight (yellow) - Some Definitions > Location 2131
An Agile methodology promoting time- boxed cycles, team self- organization, and high team accountability. Scrum is the most popular form of Agile.
Highlight (pink) - Some Definitions > Location 2133
User story
Highlight (yellow) - Some Definitions > Location 2134
The smallest unit of work expressed as a benefit to the end user. Typical user stories are written using the following syntax:
Highlight (pink) - Some Definitions > Location 2136
As a [user type]
Highlight (pink) - Some Definitions > Location 2136
I want to [accomplish something]
Highlight (pink) - Some Definitions > Location 2136
So that [some benefit happens]
Highlight (pink) - Some Definitions > Location 2137
Backlog
Highlight (yellow) - Some Definitions > Location 2138
A prioritized list of user stories. The backlog is the most powerful project management tool in Agile. It is through the active grooming of the backlog that the team manages their daily workload and refocuses their efforts based on incoming learnings. It is how the team stays Agile.
Highlight (pink) - Some Definitions > Location 2140
Sprint
Highlight (yellow) - Some Definitions > Location 2141
A single cycle of work for a team. The goal of each sprint is to deliver working software. Most Scrum teams work in two- week sprints.
Highlight (pink) - Some Definitions > Location 2143
Stand- up
Highlight (yellow) - Some Definitions > Location 2143
A daily, short team meeting during which each member addresses the day’s challenges.
Highlight (pink) - Some Definitions > Location 2146
Retrospective
Highlight (yellow) - Some Definitions > Location 2146
A meeting at the end of each sprint that takes an honest look at what went well, what went poorly, and how the team will try to improve process in the next sprint. Your process is as iterative as your product. Retrospectives give your team the chance to optimize your process with every sprint.
Highlight (pink) - Some Definitions > Location 2149
Iteration planning meeting
Highlight (yellow) - Some Definitions > Location 2150
A meeting at the beginning of each sprint during which the team plans what they’ll be doing during the upcoming sprint. Sometimes, this meeting includes estimation and story gathering. This is the meeting that determines the initial prioritization of the backlog.
Highlight (pink) - Some Definitions > Location 2153
Product discovery
Highlight (yellow) - Some Definitions > Location 2154
A term used to describe any learning activities the team undertakes to help them determine what to deliver. Lean UX powers the product discovery process.
Highlight (pink) - Some Definitions > Location 2155
Sprint zero
Highlight (yellow) - Some Definitions > Location 2156
This is the time before product delivery begins that many organizations set aside for product discovery. It can extend beyond one sprint. Our goal is to ensure that, even if you’re using the sprint- zero model, it is not the only time that testing, learning, and validation take place.
Highlight (pink) - Some Definitions > Location 2159
Design sprint
Highlight (yellow) - Some Definitions > Location 2159
A term popularized by the design team at Google Ventures used to describe a time- boxed collection of collaborative activities that help a team move quickly from ideas to prototypes. Running a design sprint as “sprint zero” is an increasingly common practice.
Highlight (pink) - Some Definitions > Location 2162
Dual- track Agile
Highlight (yellow) - Some Definitions > Location 2163
Popularized by product management guru Marty Cagan, dual- track Agile is an attempt to build a continuous product discovery and delivery model for Scrum teams. It champions a process in which teams manage two backlogs— a discovery backlog and a delivery backlog. They work through their discovery backlogs with only validated items graduating into the delivery cycle. In many ways, if executed well, this is the end state most teams should strive for; however, it is not without its challenges.
Highlight (blue) - Staggered Sprints and Their Modern Offshoots > Location 2168
Staggered Sprints and Their Modern Offshoots
Highlight (yellow) - Staggered Sprints and Their Modern Offshoots > Location 2168
In May 2007, Desiree Sy and Lynn Miller published “Adapting Usability Investigations for Agile User- centered Design” in the Journal of Usability Studies. 1 Sy and Miller were some of the first people to try to combine Agile and UX, and many of us were excited by the solutions they were proposing.
Highlight (yellow) - Staggered Sprints and Their Modern Offshoots > Location 2179
In short, Sy and Miller described a process in which design activity takes place one sprint ahead of development. Work is designed and validated during the “design sprint” and then passed off into the development stream to be implemented during the development sprint, as is illustrated in Figure 7- 1.
Highlight (yellow) - Staggered Sprints and Their Modern Offshoots > Location 2183
Figure 7- 1. Sy and Miller’s “Staggered Sprints” model
Highlight (yellow) - Staggered Sprints and Their Modern Offshoots > Location 2184
Many teams have misinterpreted this model, though. Sy and Miller always advocated strong collaboration between designers and developers during both the design and development sprints. Many teams have missed this critical point and instead have created workflows in which designers and developers communicate by handoff— creating a kind of mini- waterfall process.
Highlight (yellow) - Staggered Sprints and Their Modern Offshoots > Location 2195
Here’s why: it becomes very easy to create a situation in which the entire team is never working on the same thing at the same time. You never realize the benefits of cross- functional collaboration because the different disciplines are focused on different things. Without that collaboration, you don’t build shared understanding, so you end up relying heavily on documentation and handoffs for communication.
Highlight (yellow) - Staggered Sprints and Their Modern Offshoots > Location 2198
There’s another reason this process is less than ideal: it can create unnecessary waste. You waste time creating documentation to describe what happened during the design sprints.
Highlight (blue) - Staggered Sprints and Their Modern Offshoots > Location 2203
Evolving the Design Sprint
Highlight (yellow) - Staggered Sprints and Their Modern Offshoots > Location 2203
These days, the term “design sprint” has taken on a new meaning. The term is now associated with the ideas in the book Sprint by Jake Knapp, John Zeratsky, and Braden Kowitz (Simon & Schuster).
Highlight (yellow) - Staggered Sprints and Their Modern Offshoots > Location 2208
They describe a design sprint as a way to bring together all the key stakeholders on a new project or initiative. Working closely together over the course of five days, this cross- functional team brainstorms, iterates, and works their way through a series of ideas.
Highlight (yellow) - Staggered Sprints and Their Modern Offshoots > Location 2210
The week culminates with a prototype. In most cases, the resulting prototype has even had a round or two of customer research applied to it.
Highlight (yellow) - Staggered Sprints and Their Modern Offshoots > Location 2211
This is a technique that we’ve used many times in our own practice (based on the time- honored Design Studio method, described in Chapter 4).
Highlight (yellow) - Staggered Sprints and Their Modern Offshoots > Location 2214
In our experience, the ideal result of a design sprint is a backlog of hypotheses. This prioritized list of risks defines the work that the team must continue to validate throughout the project lifecycle.
Highlight (yellow) - Staggered Sprints and Their Modern Offshoots > Location 2218
There are a few pitfalls to watch out for when running a full five- day design sprint:
Highlight (pink) - Staggered Sprints and Their Modern Offshoots > Location 2220
Use them on the right projects
Highlight (yellow) - Staggered Sprints and Their Modern Offshoots > Location 2220
Ensure that the problem space you’re exploring is big enough to warrant putting your entire team in a room for five days.
Highlight (pink) - Staggered Sprints and Their Modern Offshoots > Location 2223
Keep the team size small
Highlight (yellow) - Staggered Sprints and Their Modern Offshoots > Location 2223
Design sprints are touted as a great tool for collaboration. This is true, but collaboration can get diluted if too many people are involved. Run these sprints with the core team and their immediate stakeholders. Try to keep the participant number to about 10 people.
Highlight (pink) - Staggered Sprints and Their Modern Offshoots > Location 2225
Adapt the recipe to your needs
Highlight (yellow) - Staggered Sprints and Their Modern Offshoots > Location 2226
There are many detailed descriptions of exactly how to facilitate a design sprint. These are phenomenal resources for early practitioners of this technique. But don’t become stuck following the rules.
Highlight (pink) - Staggered Sprints and Their Modern Offshoots > Location 2229
Learning doesn’t end at the end of the design sprint
Highlight (yellow) - Staggered Sprints and Their Modern Offshoots > Location 2230
Design sprints are exciting, high- energy bursts of work. But it’s hard to sustain that energy. We’ve seen teams emerge energized and motivated to get building. But learning shouldn’t end when the design sprint ends. As the product progresses and evolves, new questions will come up, and they require further discovery.
Highlight (blue) - Dual-Track Agile > Location 2235
Dual- Track Agile
Highlight (yellow) - Dual-Track Agile > Location 2235
In many ways, dual- track Agile is what Sy and Miller were trying to convey with their staggered- sprint model.
Highlight (yellow) - Dual-Track Agile > Location 2237
Marty Cagan, Jeff Patton, and others advocate for a process in which a single team manages two backlogs: a discovery backlog and a delivery backlog. The team splits into two units to do the work: a discovery unit and a delivery unit.
Highlight (yellow) - Dual-Track Agile > Location 2242
The discovery unit works through the discovery items, running experiments and speaking to customers in an effort to discover which ideas merit further exploration and which don’t.
Highlight (yellow) - Dual-Track Agile > Location 2243
Ideas that graduate from discovery to delivery are built by the delivery unit of the team.
Highlight (yellow) - Dual-Track Agile > Location 2244
This reduces the amount of documentation necessary to drive the delivery process because the people who validated the feature are in close contact with, or in some cases are, the same people who design and implement it. Figure 7- 2 offers an overview of the process.
Highlight (yellow) - Dual-Track Agile > Location 2247
Figure 7- 2. Marty Cagan’s dual- track Agile process diagram (image courtesy of Marty Cagan)
Highlight (pink) - Dual-Track Agile > Location 2251
Separate discovery and delivery teams
Highlight (yellow) - Dual-Track Agile > Location 2252
One antipattern we’ve witnessed several times is teams splitting up who does the discovery and who does the delivery on their team.
Highlight (yellow) - Dual-Track Agile > Location 2255
Often the UX designer and/ or the product manager take on the bulk of the discovery work. The engineers are delegated early delivery work.
Highlight (yellow) - Dual-Track Agile > Location 2255
This effectively recreates the mini- waterfalls of staggered sprints, as described earlier.
Highlight (pink) - Dual-Track Agile > Location 2261
Limited knowledge of how to do discovery
Highlight (yellow) - Dual-Track Agile > Location 2261
Building a dual- track Agile process assumes that your team knows how to do discovery. There are many tools that you can use to build feedback loops into a discovery backlog.
Highlight (yellow) - Dual-Track Agile > Location 2263
Without a broader knowledge of these tools, teams resort to the ones they’re most familiar with, and often pick suboptimal tactics for learning.
Highlight (yellow) - Dual-Track Agile > Location 2265
Seasoned practitioners can teach your team the best method for your needs and can help you plan your discovery work.
Highlight (pink) - Dual-Track Agile > Location 2266
Not feeding back evidence from the delivery work to the discovery backlog
Highlight (yellow) - Dual-Track Agile > Location 2267
This challenge is symptomatic of an organization that is still thinking incrementally. After a feature makes it from discovery to delivery, the team will implement it as designed and ship it.
Highlight (yellow) - Dual-Track Agile > Location 2269
The great thing about that is that, as soon as it’s live, this new feature begins to provide a new set of data about how well it’s working and where to focus your next discovery activities.
Highlight (blue) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2273
Exploiting the Rhythms of Scrum to Build a Lean UX Practice
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2274
Over the years, we’ve found some useful ways to integrate Lean UX approaches with the rhythms of Scrum. Let’s take a look at how you can use Scrum’s meeting cadence and Lean UX to build an efficient process.
Highlight (blue) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2278
Themes
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2278
Scrum has a lot of meetings. Many people frown on meetings, but if you use them as mileposts during your sprint you can create an integrated Lean UX and Agile process in which the entire team is working on the same thing at the same time.
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2282
Let’s assume that you’ve chosen a risky hypothesis as the early focus of your project. You can use that hypothesis to create a theme that guides the work you’ll do over the next set of sprints, as demonstrated in Figure 7- 3.
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2284
Figure 7- 3. Sprints tied together with a theme
Highlight (blue) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2286
Kick Off the Theme with a Design Sprint
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2287
Start work on each theme with some version of a Design Studio or design sprint. (See Figure 7- 4.)
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2290
Depending on the scope of the hypothesis, the design sprint can be as short as an afternoon or as long as a week.
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2293
The point of this kickoff is to get the entire team sketching, ideating, and speaking to customers together, creating a backlog of ideas from which to test and learn.
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2295
After you’ve started your regular sprints, your ideas will be tested, validated, and developed: new insights will come in, and you’ll need to decide what to do with them.
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2297
You make these decisions by running subsequent shorter brainstorming sessions and collaborative discovery activities before each new sprint begins. This allows the team to use the latest insight to create the backlog for the next sprint.
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2299
Figure 7- 4. Timing and scope of design sprints
Highlight (blue) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2301
Iteration Planning Meeting
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2301
Bring the output of your design sprint to the iteration planning meeting (IPM).
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2304
Your mess of sticky notes, sketches, wireframes, paper prototypes, and any other artifacts might seem useless to outside observers but will be meaningful to your team.
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2305
You made these artifacts together and because of that you have the shared understanding necessary to extract stories from them. Use them in your IPM to write user stories together, and then estimate and prioritize the stories. (See Figure 7- 5.)
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2308
Figure 7- 5. Hold iteration planning meetings immediately after brainstorming sessions Experiment Stories
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2310
As you plan your iteration, there might be additional discovery work that needs to be done during the iteration that wasn’t covered in the design sprint or collaborative discovery activities.
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2314
To accommodate this in your sprint cadence use experiment stories. Captured by using the same method as your user stories, experiment stories have two distinct benefits:
Highlight (pink) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2316
They visualize discovery work
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2317
Discovery work is not inherently tangible as delivery work can be. Experiment stories solve that by leveling the playing field. Everything your team works on— discovery or delivery— goes on the backlog as a story.
Highlight (pink) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2318
They force its prioritization against delivery work
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2319
After those stories are in the backlog, you need to put them in priority order. This forces conversations around when to run the experiment and, equally as important, what we won’t be working on during that same time.
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2321
Experiment stories look just like user stories, as illustrated in Figure 7- 6.
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2323
Figure 7- 6. Experiment stories
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2323
Experiment stories contain the following elements:
Highlight (pink) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2324
The hypothesis you’re testing or the thing you’re trying to learn
Highlight (pink) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2325
Tactic( s) for learning (e.g., customer interviews, A/ B tests, and prototypes)
Highlight (pink) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2326
Who will do the work
Highlight (pink) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2326
A level of effort estimate (if you do estimations) for how much work you expect this to be
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2327
After they are written, experiment stories go into your backlog. When their time comes up in the sprint, that’s the assigned person’s main focus. When the experiment is over, bring the findings to the team immediately and discuss them to determine the impact of these findings. Your team should be ready to change course, even within the current sprint, if the outcome of the experiment stories reveals insights that invalidate your current prioritization.
Highlight (blue) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2331
User Validation Schedule
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2331
Finally, to ensure that you have a constant stream of customer feedback to use for your experiments, plan user research sessions every single week. (See Figure 7- 7.)
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2334
This way your team is never more than five business days away from customer feedback and has ample time to react prior to the end of the sprint. This weekly research cadence provides a good rhythm for your experiment stories as well as a natural learning point in the sprint.
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2337
Remember that when the ideas are raw, you are testing for value (that is, do people want to use my product?). After you have established that there is a desire for your product, subsequent tests with higher- fidelity artifacts will reveal whether your solution is usable.
Highlight (yellow) - Exploiting the Rhythms of Scrum to Build a Lean UX Practice > Location 2340
Figure 7- 7. Conversations with users happen every week
Highlight (blue) - Participation > Location 2341
Participation
Highlight (yellow) - Participation > Location 2341
Agile methods can create a lot of time pressure on designers. Some work fits easily into the context of a user story. Other work needs more time to get right. Two- week cycles of concurrent development and design offer few opportunities for designers to ruminate on big problems.
Highlight (yellow) - Participation > Location 2348
And although some Agile methods take a more flexible approach to time than Scrum does (for example, Kanban does away with the notion of a two- week batch of work, and places the emphasis on continuous flow), most designers feel pressure to fit their work into the time- box of the sprint. For this reason, designers need to participate in the sprint- planning process.
Highlight (yellow) - Participation > Location 2350
The major reason designers feel pressure in Agile processes is that they don’t (for whatever reason) fully participate in the process.
Highlight (yellow) - Participation > Location 2353
As a result, many Agile teams don’t make plans that allow designers to do their best work.
Highlight (yellow) - Participation > Location 2354
For Lean UX to work in Agile, the entire team must participate in all activities— stand- ups, retrospectives, IPMs, brainstorming sessions— they all require everyone’s attendance to be successful.
Highlight (yellow) - Participation > Location 2357
For example, imagine at the beginning of a sprint that the first story a team prioritizes has a heavy design component to it. Imagine that the designer was not there to voice her concern.
Highlight (yellow) - Participation > Location 2359
The designer will cry out that the story has not been designed. She will say that it will take at least two to three days to complete the design before the story is ready for development.
Highlight (yellow) - Participation > Location 2362
The other casualty of sparse participation is shared understanding. Teams make decisions in meetings. Those decisions are based on discussions. Even if 90 percent of a meeting is not relevant to your immediate need, the 10 percent that is relevant will save hours of time downstream explaining what happened at the meeting and why certain decisions were made.
Highlight (blue) - Participation > Location 2367
Design Is a Team Sport
Highlight (yellow) - Participation > Location 2367
In the following case study, designer and coach Lane Goldstone details how she brought to the table all the players— development, design, marketing, stakeholders— to create a tablet game.
Highlight (blue) - Case Study: Knowsy (by Lane Goldstone) > Location 2370
Case Study: Knowsy (by Lane Goldstone)
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2370
In my work as a product designer, I use Lean UX practices on a variety of projects. Recently I’ve worked on entertainment, ecommerce, and social- media products for different platforms, including iPad, iPhone, and the Web. The teams have been small, ranging from three to seven people. Most of my projects also share the following characteristics:
Highlight (pink) - Case Study: Knowsy (by Lane Goldstone) > Location 2375
The project is run within an Agile framework
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2375
(focus on the customer, continuous delivery, team sits together, lightweight documentation, team ownership of decisions, shared rituals like stand- ups, retrospectives, and so on).
Highlight (pink) - Case Study: Knowsy (by Lane Goldstone) > Location 2376
The team contains people with a mix of skills
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2376
(frontend and backend development, user experience and information architecture, product management and marketing, graphic design, and copywriting).
Highlight (pink) - Case Study: Knowsy (by Lane Goldstone) > Location 2378
The people on the team generally performed in their area of expertise/ strength,
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2378
but were supportive of other specialties and interested in learning new skills.
Highlight (blue) - Case Study: Knowsy (by Lane Goldstone) > Location 2382
The Innovation Games Company
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2383
The Innovation Games Company (TIGC) produces serious games— online and in- person— for market research.
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2385
TIGC helps organizations get actionable insights into customer needs and preferences to improve performance through collaborative play.
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2387
I was part of the team that created Knowsy for iPad (Figure 7- 8), a pass-‘ n’- play game that’s all about learning what you know about your friends, family, and coworkers— while simultaneously testing how well they know you.
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2389
The person who knows the other players best wins the game. It is fast, fun, and a truly “social” game for up to six players.
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2389
It was our first iPad application, and we had an ambitious deadline: one month to create the game and have it accepted to the Apple Store. Our small team had a combination of subject- matter expertise and skills in frontend and backend development as well as visual and interaction design.
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2393
Figure 7- 8. The Knowsy team with the wall of artifacts behind them
Highlight (blue) - Case Study: Knowsy (by Lane Goldstone) > Location 2395
A Shared Vision Empowers Independent Work
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2395
Until a new product is coded, it’s difficult for people to work within the same product vision. You can recognize a lack of shared vision when the team argues about what features are important or what should be done first.
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2398
There can also be a general sense of tension that the team is not “moving fast enough” or it feels like the team is going back over the same issues again and again.
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2399
While working on Knowsy, I looked for ways that I could make my UX practice more quick, visual, collaborative, and continuous. I looked for opportunities to work in real time with other people on the team (such as developers and the product manager) and rough things out as quickly as possible at the lowest responsible level of fidelity.
Highlight (blue) - Case Study: Knowsy (by Lane Goldstone) > Location 2403
Breaking the Design Bottleneck
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2404
Early in the project, I sat with the frontend developer to talk about the game design.
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2405
We created a high- level game flow together on paper (Figure 7- 9), passing the marker back and forth as we talked.
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2407
As we sketched, I was able to point out inconsistencies by asking questions like, “What do we do when this happens?” This approach had the benefit of changing the dialog from, “I’m right- you’re wrong,” to “How do we solve this problem?”
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2409
After we had this basic agreement, I was able to create a paper prototype of the game based on the flow and we play tested it with the team. The effect on the team was immediate. Suddenly, everyone “got it” and was excited about what we were doing. People began to contribute ideas that fit well together, and we were able to identify what parts we could each work on that supported the whole.
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2414
Figure 7- 9. The paper prototype begins to take shape
Highlight (blue) - Case Study: Knowsy (by Lane Goldstone) > Location 2415
The Outcome
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2416
Knowsy’s foray into Lean UX proved a success. We got the app to the Apple Store in time for the deadline. I was called back later to help the team do another variant of the product.
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2418
For that go- around, I used a similar process. Because I was working remotely and the development team was not as available to collaborate, I had to make heavier deliverables. Nevertheless, the basic principle of iterating our way to higher fidelity continued.
Highlight (yellow) - Case Study: Knowsy (by Lane Goldstone) > Location 2421
Figure 7- 10. Lane updating the prototype and artifact wall in real time
Highlight (blue) - Beyond the Scrum Team > Location 2422
Beyond the Scrum Team
Highlight (yellow) - Beyond the Scrum Team > Location 2423
Management check- ins are one of the biggest obstacles to maintaining team momentum. Designers are used to doing design reviews, but unfortunately, check- ins don’t end there. Product owners, stakeholders, CEOs, and clients all want to know how things are going.
Highlight (yellow) - Beyond the Scrum Team > Location 2429
They all want to bless the project plan going forward. The challenge for outcome- focused teams is that their project plans are dependent on what they are learning. They are responsive, so their typical plan lays out only small batches of work at a time. At most, these teams plan an iteration or two ahead. This perceived “short- sightedness” tends not to satisfy most high- level managers. How then do you keep the check- ins at bay while maintaining the pace of your Lean UX and Scrum processes?
Highlight (blue) - Beyond the Scrum Team > Location 2433
Two words: proactive communication.
Highlight (yellow) - Beyond the Scrum Team > Location 2434
Jeff once managed a team that radically altered the workflow for an existing product that had thousands of paying customers. The team was so excited by the changes they’d made that they went ahead with the launch without alerting anyone else in the organization.
Highlight (yellow) - Beyond the Scrum Team > Location 2435
Within an hour of the new product going live the vice president of customer service was at Jeff’s desk, fuming and demanding to know why she wasn’t told of this change. The issue was this: when customers have problems with the product, they call in for help. Call center representatives use scripts to troubleshoot customer problems and to offer solutions— except they didn’t have a script for this new product. Because they didn’t know it was going to change.
Highlight (yellow) - Beyond the Scrum Team > Location 2439
This healthy slice of humble pie served as a valuable lesson. If you want your stakeholders— both those managing you and those dependent on you— to stay out of your way, make sure that they are aware of your plans.
Highlight (pink) - Beyond the Scrum Team > Location 2441
Maintain a “Problem Roadmap.”
Highlight (yellow) - Beyond the Scrum Team > Location 2442
Use this Problem Roadmap to drive planning and check- in meetings with stakeholders.
Highlight (pink) - Beyond the Scrum Team > Location 2443
Proactively reach out to your product owners and executives to keep them updated on your plans.
Highlight (pink) - Beyond the Scrum Team > Location 2444
Let them know:
Highlight (pink) - Beyond the Scrum Team > Location 2444
how the project is going;
Highlight (pink) - Beyond the Scrum Team > Location 2444
what you tried so far and learned;
Highlight (pink) - Beyond the Scrum Team > Location 2445
what you’ll be trying next;
Highlight (pink) - Beyond the Scrum Team > Location 2445
what risks you see in the product and how you plan to address them.
Highlight (pink) - Beyond the Scrum Team > Location 2445
Keep the conversations focused on outcomes (how you’re trending toward your goal) not feature sets.
Highlight (pink) - Beyond the Scrum Team > Location 2446
Ensure dependent departments (customer service, marketing, operations, etc.) are aware of upcoming changes that can affect their world.
Highlight (pink) - Beyond the Scrum Team > Location 2447
Provide them with plenty of time to update their workflows if necessary.
Highlight (blue) - Lean UX and Agile in the Enterprise > Location 2449
Lean UX and Agile in the Enterprise
Highlight (yellow) - Lean UX and Agile in the Enterprise > Location 2449
Many of the tactics covered in this book are focused on one team. But in the real world, enterprise organizations have multiple product development teams working in parallel.
Highlight (yellow) - Lean UX and Agile in the Enterprise > Location 2453
How does Lean UX scale when the number of teams grows to tens or even hundreds of concurrent workstreams? This is the question of the moment in the Agile community. As Lean and Agile methods have become more mainstream, and as they have become the default working style for technology teams across industries, many people have become focused on this question.
Highlight (yellow) - Lean UX and Agile in the Enterprise > Location 2455
Large organizations have a legitimate need to coordinate the activity of multiple teams— processes based on learning your way forward present a challenge to most traditional project management methods.
Highlight (yellow) - Lean UX and Agile in the Enterprise > Location 2457
A full discussion of how to create a truly Agile and Lean organization is beyond the scope of this book. It requires leadership to radically rethink the way it sets strategy, assembles teams, and plans and assigns work.
Highlight (yellow) - Lean UX and Agile in the Enterprise > Location 2459
Here are just a few issues that typically arise and ways to manage for them:
Highlight (pink) - Lean UX and Agile in the Enterprise > Location 2460
Issue
Highlight (yellow) - Lean UX and Agile in the Enterprise > Location 2460
As projects grow bigger, more teams are assigned to them. How do you ensure that all teams are aligned to the same vision and not optimizing locally?
Highlight (pink) - Lean UX and Agile in the Enterprise > Location 2462
Solution
Highlight (yellow) - Lean UX and Agile in the Enterprise > Location 2462
The concept of managing to outcomes applies to a set of teams as much as it does to individual ones. To ensure that all the teams working on the same project have a shared vision, assign them all the same success metric.
Highlight (yellow) - Lean UX and Agile in the Enterprise > Location 2466
But teams must not be allowed to focus on leading metrics to the exclusion of the larger outcome: the entire set of teams succeeds only if they hit the overarching outcome together.
Highlight (pink) - Lean UX and Agile in the Enterprise > Location 2467
Issue
Highlight (yellow) - Lean UX and Agile in the Enterprise > Location 2468
How do you ensure that teams are sharing what they’re learning and minimizing duplicate effort to learn the same things?
Highlight (pink) - Lean UX and Agile in the Enterprise > Location 2469
Solution
Highlight (yellow) - Lean UX and Agile in the Enterprise > Location 2470
Although there’s no silver bullet to solve for this issue, the successful practices we’ve seen include a central knowledge management tool (like a wiki), regular team leadership meetings (like a Scrum of Scrums), and open- communication tools that focus on research (like a dedicated channel on Slack or your internal chat tool).
Highlight (pink) - Lean UX and Agile in the Enterprise > Location 2472
Issue
Highlight (yellow) - Lean UX and Agile in the Enterprise > Location 2473
Cross- team dependencies can keep progress at a crawl. How do you maintain a regular pace of learning and delivery in a multiteam environment?
Highlight (pink) - Lean UX and Agile in the Enterprise > Location 2474
Solution
Highlight (yellow) - Lean UX and Agile in the Enterprise > Location 2475
Create self- sufficient “full- stack” teams. Full- stack teams have every capability needed for them to do their work on the team. This doesn’t mean that they need a person from each department— just that there is someone on the team who can do one or more of the things the team might need.
Highlight (yellow) - Lean UX and Agile in the Enterprise > Location 2477
The specific disciplines on the team— designers, content people, frontend developers, backend developers, product managers— coordinate with one another at discipline- specific meetings to ensure that they are up- to- date on their practice, but the work takes place locally.
Highlight (yellow) - Lean UX and Agile in the Enterprise > Location 2479
This chapter took a closer look at how Lean UX fits into an Agile process. In addition, we looked at how cross- functional collaboration allows a team to move forward at a brisk pace, and how to handle stakeholders and managers who always want to know what’s going on.
Highlight (yellow) - Lean UX and Agile in the Enterprise > Location 2481
We discussed why having everyone participate in all activities is critical and how the staggered- sprint model, once considered the path to true agility, has evolved into design sprints and dual- track product discovery and delivery.


--- title: Endorsements layout: default bodyClass: page-testimonials-list ---
Kathleen is a "hands-on" activist in our community, working hard to improve the lives of residents and advocating for accountability in our city government. Her passion to serve is evident in what she is doing right now.
I believe a City Council should reflect and represent the whole community. I believe Kathleen Beckman is prepared to do just that for Clearwater and for you. I recommend her election to Seat 3.
The Sierra Club Suncoast group is excited to endorse Kathleen for the Clearwater City council. She will bring strong leadership to establish goals for saving the city money while protecting the environment, which is critical to Clearwater residents and their economy.
Through Kathleen’s experiences as a teacher and hands-on volunteering in the community, she knows how to engage and support what is important to families.
I support Kathleen Beckman for Clearwater City Council because I know she listens to the needs of small businesses in our community and is willing to work on removing barriers that can make it challenging to flourish. She wants all businesses to be successful and is particular interested in supporting new entrepreneurs, diversity in types of businesses and in business ownership.
Kathleen listens to owners and operators of small businesses. She knows about our unique needs and concerns. As a city council member, she will be a strong advocate for residents and businesses.
Kathleen is really engaging small business owners and finding out what is important to them for their business to thrive. I look forward to working with her to solve every day challenges for my business and other businesses across the city.
We need people like Kathleen on the council who will represent residents and neighborhoods, and truly work with all members of our community to learn about their concerns and meet their diverse needs.
I strongly support Kathleen for her dedication and persistent efforts to personally connect with Clearwater residents and gain an understanding of issues in our neighborhoods. Her public comments made at Environmental Advisory Board meetings clearly express a commitment to the protection of the City's natural resources and a progressive approach to the pursuit of sustainable principles for the environment. As a career educator her ability to listen and give thoughtful consideration to complex matters before espousing an opinion is refreshing. Kathleen will be a voice on the City Council that represents the interests of the residents.
Kathleen is an active volunteer in our community, including as a member of the NAACP. She is willing to put in the hard work, to listen, and to collaborate with a variety of people. She is committed to working to improve the lives of everyday residents here in Clearwater. She will bring new energy, diversity, and accountability to our Council.
Kathleen will bring energy, collaboration, diversity and a passion for transparency and accountability to the council.
Kathleen is a leader in our community who supports the well-being of our children and families. Her commitment to making our communities a better place is second to none. She will be a strong advocate for families and neighborhoods serving on the Clearwater City Council.
Kathleen understands the issues affecting professionals and small businesses operating in Clearwater and the regulations and hurdles that sometimes slow down getting things done. She is extremely well informed in the operations of the City and I look forward to working with her on the issues facing my practice and those of other professionals and businesses across the city.
Kathleen is the kind of hard worker that our City desperately needs. Since she decided to run for City Council, she has taken so much time and energy to go out into the neighborhoods to understand what residents truly need, instead of focusing on political issues. Kathleen has my vote because she stands for sustainability in life and business, and will fight for affordable housing in our community.
Kathleen cares about small businesses. She is particularly interested in bringing more diversity in both business ownership and in types of businesses, and in reducing the challenges of starting a new business. She has also been supportive of me and my efforts to educate and empower young adults here in Clearwater.
Kathleen Beckman is the leader Clearwater needs. She will address the critical issues--protecting our environment, using our resources wisely--and work effectively with others for the benefit of all.
I have known Kathleen for nearly three years. She approached me about joining our Panther Pal reading program in the spring of 2017 after having just learned about it. And although we only had a few months left of the school year, she didn't want to wait until the following fall to become engaged with helping our struggling readers. Kathleen is a dedicated volunteer who uses her professional talents to engage with our diverse student population and improve students' reading scores. She has also shown great leadership skills in forming a swim team for the local YMCA.


Copyright © 2016 Guilherme Andrade
Version: 2.0.1
Authors: Guilherme Andrade (erlchronos(at)gandrade(dot)net).
erlchronos
: Erlang/OTP gen_server wrapper with ticks
erlchronos
provides a gen_server
wrapper, ticked_gen_server
,
that allows one to more easily manage triggering and dealing with ticks at regular intervals by specifying two new callbacks,
tick_duration/2
and handle_tick/4
.
It also does away with the usual erlang:send_after/3
,
timer:send_interval/2
, etc. approaches, instead relying
on two key mechanisms for tick enforcement:
* gen_server
's support for specifying timeout values on callbacks - which takes care of idle-inbox periods;
* An active verification of triggering conditions on key events (inits, calls, casts and infos) - which takes care of busier periods.
The traditional approach of having a message sent to a gen_server
's inbox at regular intervals isn't always
the more appropriate, and might misbehave significantly every time the system is subjected to message bursts (among other factors), even when actively accounting for drift, due to the strictly-ordered nature of inbox consumption.
An alternative would be to change the receive
logic itself and pattern-match against timer / higher-priority messages, but this would quickly degrade performance on flooded inboxes and create a degeneration feedback loop.
This compromise solution tries not to fiddle too much with, nor reinvent the existing building blocks.
* Ticks should be more precise, save for enormously flooded inboxes (whose processes never behave properly, in any case;)
* For overload scenarios, the tick_duration/2
callback can be used to easily lower tick rate;
* Ticking logic is abstracted away.
* Slight execution overhead;
* Losing the ability of specify timeouts on init
/ handle_call
/ handle_cast
/ handle_info
return values;
* Losing the ability of receiving messages (on handle_info
) made only of the 'timeout' atom.
start
/start_link
option:
ticked_gen_server:start(?MODULE, [], [{ticks, ["tick identifier"]}]).
* Implement the ticked_gen_server
behaviour, which includes two extra callbacks:
% TickDuration in milliseconds
-spec tick_duration(TickId :: term(), State :: term())
-> {TickDuration :: pos_integer(), NewState :: term()}.
tick_duration("tick identifier", State) ->
{100, State}.
-spec handle_tick(TickId :: term(), TickGeneration :: non_neg_integer(),
ActualTickDuration :: non_neg_integer(), State :: term())
-> {noreply, NewState :: term()}.
handle_tick(TickId, TickGeneration, ActualTickDuration, State) ->
% Tick!
{noreply, State};
Basic example under examples/.
* When a gen_server receives events whose handling time equals to a big enough fraction of the tick duration, it risks provoking unacceptable jitter; * When a gen_server's exection is blocked, incoming ticks risk being triggered in a burst fashion later on, but ignoring them is easy enough to do if such is a requirement.
ticked_gen_server
to gain some insight into predicted execution times and, based on this knowledge, preemptively sacrifice execution capacity (by sleeping) and trade it for a lower likelihood of jitter;
* Wrap gen_fsm
/ gen_event
in a similar fashion.
Generated by EDoc, Apr 30 2017, 18:40:45.


<- list(
deps "arm",
"car",
"corrplot",
"FRK",
"gghighlight",
"ggplot2",
"ggmap",
"gridExtra",
"gstat",
"hexbin",
"jtools",
"kableExtra",
"knitr",
"lme4",
"lmtest",
"lubridate",
"MASS",
"merTools",
"plyr",
"RColorBrewer",
"rgdal",
"sf",
"sjPlot",
"sp",
"spgwr",
"spatialreg",
"spacetime",
"stargazer",
"tidyverse",
"tmap",
"tufte",
"viridis"
)
1 Overview
Access to all materials, including lecture notes, computational notebooks and datasets, is centralised through the use of the course website available in the following url:
The module handbook, including the assessment description, criteria and module programme, and videos for each teaching week can be accessed via the module Canvas site:
1.1 Aims
This module aims to provides students with a range of techniques for analysing and modelling spatial data:
- build upon the more general research training delivered via companion modules on Data Collection and Data Analysis, both of which have an aspatial focus;
- highlight a number of key social issues that have a spatial dimension;
- explain the specific challenges faced when attempting to analyse spatial data;
- introduce a range of analytical techniques and approaches suitable for the analysis of spatial data; and,
- enhance practical skills in using R software packages to implement a wide range of spatial analytical tools.
1.2 Learning Outcomes
By the end of the module, students should be able to:
- identify some key sources of spatial data and resources of spatial analysis and modelling tools;
- explain the advantages of taking spatial structure into account when analysing spatial data;
- apply a range of computer-based techniques for the analysis of spatial data, including mapping, correlation, kernel density estimation, regression, multi-level models, geographically-weighted regression, spatial interaction models and spatial econometrics;
- apply appropriate analytical strategies to tackle the key methodological challenges facing spatial analysis – spatial autocorrelation, heterogeneity, and ecological fallacy; and,
- select appropriate analytical tools for analysing specific spatial data sets to address emerging social issues facing the society.
1.3 Feedback
Formal assessment of two computational essays. Written assignment-specific feedback will be provided within three working weeks of the submission deadline. Comments will offer an understanding of the mark awarded and identify areas which can be considered for improvement in future assignments.
Verbal face-to-face feedback. Immediate face-to-face feedback will be provided during lecture, discussion and clinic sessions in interaction with staff. This will take place in all live sessions during the semester.
Online forum. Asynchronous written feedback will be provided via an online forum maintained by the module lead. Students are encouraged to contribute by asking and answering questions relating to the module content. Staff will monitor the forum Monday to Friday 9am-5pm, but it will be open to students to make contributions at all times.
1.4 Computational Environment
To reproduce the code in the book, you need the following software packages:
- R-4.2.2
- RStudio 2022.12.0-353
- Quarto 1.2.280
- the list of libraries in the next section
To check your version of:
- R and libraries run
sessionInfo()
- RStudio click
help
on the menu bar and thenAbout
- Quarto check the
version
file in the quarto folder on your computer.
To install and update:
- R, download the appropriate version from The Comprehensive R Archive Network (CRAN)
- RStudio, download the appropriate version from Posit
- Quarto, download the appropriate version from the Quarto website
1.4.1 Dependency list
The list of libraries used in this book is provided below:
arm
car
corrplot
FRK
gghighlight
ggplot2
ggmap
GISTools
gridExtra
gstat
hexbin
jtools
kableExtra
knitr
lme4
lmtest
lubridate
MASS
merTools
plyr
RColorBrewer
rgdal
sf
sjPlot
sp
spgwr
spatialreg
spacetime
stargazer
tidyverse
tmap
tufte
viridis
Copy, paste and run the code below in your console. Ensure all packages are installed on your computer.
# we can load them all to make sure they are installed:
for(lib in deps){library(lib, character.only = TRUE)}
1.5 Assessment
The final module mark is composed of the two computational essays. Together they are designed to cover the materials introduced in the entirety of content covered during the semester. A computational essay is an essay whose narrative is supported by code and computational results that are included in the essay itself. Each teaching week, you will be required to address a set of questions relating to the module content covered in that week, and to use the material that you will produce for this purpose to build your computational essay.
Assignment 1 (50%) refer to the set of questions at the end of Chapter 4, Chapter 5 and Chapter 6.  Each chapter provides more specific guidance of the tasks and discussion that you are required to consider in your assignment.
Assignment 2 (50%) refer to the set of questions at the end of Chapter 7, Chapter 8, Chapter 9 and Chapter 10.  Each chapter provides more specific guidance of the tasks and discussion that you are required to consider in your assignment.
1.5.1 Format Requirements
Both assignments will have the same requirements:
- Maximum word count: 2,000 words, excluding figures and references.
- Up to three maps, plot or figures (a figure may include more than one map and/or plot and will only count as one but needs to be integrated in the figure)
- Up to two tables.
Assignments need to be prepared in “Quarto Document” format (i.e. qmd extension) and then converted into a self-contained HTML file that will then be submitted via Turnitin. The document should only display content that will be assessed. Intermediate steps do not need to be displayed. Messages resulting from loading packages, attaching data frames, or similar messages do not need to be included as output code. Useful resources to customise your R notebook can be found on Quarto’s website.
Two Quarto Document templates will be available via the module Canvas site.
Submission is electronic only via Turnitin on Canvas.
1.5.2 Marking criteria
The Standard Environmental Sciences School marking criteria apply, with a stronger emphasis on evidencing the use of regression models, critical analysis of results and presentation standards. In addition to these general criteria, the code and outputs (i.e. tables, maps and plots) contained within the notebook submitted for assessment will be assessed according to the extent of documentation and evidence of expertise in changing and extending the code options illustrated in each chapter. Specifically, the following criteria will be applied:
- 0-15: no documentation and use of default options.
- 16-39: little documentation and use of default options.
- 40-49: some documentation, and use of default options.
- 50-59: extensive documentation, and edit of some of the options provided in the notebook (e.g. change north arrow location).
- 60-69: extensive well organised and easy to read documentation, and evidence of understanding of options provided in the code (e.g. tweaking existing options).
- 70-79: all above, plus clear evidence of code design skills (e.g. customising graphics, combining plots (or tables) into a single output, adding clear axis labels and variable names on graphic outputs, etc.).
- 80-100: all as above, plus code containing novel contributions that extend/improve the functionality the code was provided with (e.g. comparative model assessments, novel methods to perform the task, etc.).


My name is Chase McFaddin. I was born and raised in small town Kingstree, South Carolina.  I went to college at Coastal Carolina University in Myrtle
Beach, South Carolina where I graduated with a Bachelor of Science in Recreation & Sport Management. I've had
numerous jobs from cropping tobacco, working on a tree nursery, marketing department of a college athletic
department, bartending, pest control, fantasy-sport writer, jet-ski tours, and being an interpretitive park
ranger. I currently work in sales for a retailer of Verizon-Cellular Sales. My hobbies include fantasy sports,
video games, mud runs kayaking, watching lots of television and listening to podcasts to learn new things.
One of my favorite sports to watch is the NBA and the debate over the greatest players of all time is
always a
sensitive topic. However, here is the true list of the greatest 10 players of all time!
The King - Lebron James
Michael Jordan
Shaquille O' Neal
Kobe Bryant
Kevin Durant
Magic Johnson
Tim Duncan
Dirk Nowitzki
Larry Bird
Steph Curry
Work & School Experience
Williamson Farms (worked for two summers cropping tobacco)
Kingstree Recreation Department (worked for two years after school umpiring, groundskeeping, organizing
tournaments, and ordering inventory)
Wofford College (attended for one year on a baseball scholarship)
Wofford College Athletic Department (worked for the marketing department putting on halftime shows, pregame
events, and postgame interviews)
Coastal Carolina University (Graduated in 2013 with a B.S. degree in Recreation & Sport Managemnt)
Carolina Roadhouse (waited tables and bartended for 5 years)
Myrtle Beach Powersports (guided jet-ski tours for one summer)
McGradySports LLC (started own company as a fantasy sport writer and analysts for 4 years)
Myrtle Beach State Park (two year internship as an interpretitive park ranger)
Terminix Inc. (sold and serviced pest control)
Cellular Sales - Verizon Retailer (sell Verizon services and products)


Testing image:Trans
Note: Silverlight doesn't allow downloading images when run from a file system. This demo should be run from a server.
That's all Folks!


Home
Menu
Order
Place your order
Select your prefered flavour
Something-meaty
Chicken periperi
Chicken Pizza
Beef steak and mushroom
Onions and tomatoes Pizza
Classic Margherita Pizza
Pineapple and Ham Pizza
Cheese Pizza
Select size
Small @Ksh.700
Medium @Ksh.1000
Large @Ksh.1400
Choose your favourite crust
Cripsy @Ksh.300
Stuffed @Ksh.200
Glutten-free @Ksh.150
Choose your favourite topping
Cheese @Ksh.200
Bacon @Ksh.200
Sausage @Ksh.150
Brocolli @Ksh.150
Number of Pizza
Order
Receipt
Flavour
Size
Crust
Topping
Number of Pizza
Total
delete
Your total cost for order pizza is
Pay via
Check-out
Home Delivery!
Home Delivery
Name
Location
Phone number
Deliver


public abstract class ARActivity extends Activity implements CameraEventListener
supplyFrameLayout
.
To create a custom AR experience, the subclass should also provide a custom renderer using
Renderer
. This allows the subclass to handle OpenGL drawing calls on its own.| Modifier and Type | Field and Description |
|---|---|
protected FrameLayout |
mainLayout
Layout that will be filled with the camera preview and GL views.
|
protected int |
pattCountMax
For any square template (pattern) markers, the maximum number
of markers that may be loaded for a single matching pass.
|
protected int |
pattSize
For any square template (pattern) markers, the number of rows
and columns in the template.
|
protected ARRenderer |
renderer
Renderer to use.
|
protected static java.lang.String |
TAG
Android logging tag for this class.
|
| Constructor and Description |
|---|
ARActivity() |
| Modifier and Type | Method and Description |
|---|---|
void |
cameraPreviewFrame(byte[] frame)
Called when the camera preview has a new frame ready.
|
void |
cameraPreviewStarted(int width,
int height,
int rate,
int cameraIndex,
boolean cameraIsFrontFacing)
Called when the camera preview is started.
|
void |
cameraPreviewStopped()
Called when the capture preview is stopped.
|
CaptureCameraPreview |
getCameraPreview()
Returns the camera preview that is providing the video frames.
|
GLSurfaceView |
getGLView()
Returns the GL surface view.
|
void |
onCreate(Bundle savedInstanceState) |
boolean |
onCreateOptionsMenu(Menu menu) |
void |
onFrameProcessed() |
boolean |
onOptionsItemSelected(MenuItem item) |
protected void |
onPause() |
void |
onResume() |
protected void |
onStart() |
void |
onStop() |
protected void |
showInfo() |
protected abstract FrameLayout |
supplyFrameLayout()
Allows subclasses to supply a
FrameLayout which will be populated
with a camera preview and GL surface view. |
protected abstract ARRenderer |
supplyRenderer()
Allows subclasses to supply a custom
Renderer . |
protected static final java.lang.String TAG
protected ARRenderer renderer
Renderer()
.protected FrameLayout mainLayout
supplyFrameLayout()
.protected int pattSize
protected int pattCountMax
public void onCreate(Bundle savedInstanceState)
protected abstract ARRenderer supplyRenderer()
Renderer
.Renderer
to use.protected abstract FrameLayout supplyFrameLayout()
FrameLayout
which will be populated
with a camera preview and GL surface view.FrameLayout
to use.protected void onStart()
public void onResume()
protected void onPause()
public void onStop()
public boolean onCreateOptionsMenu(Menu menu)
public boolean onOptionsItemSelected(MenuItem item)
public CaptureCameraPreview getCameraPreview()
public GLSurfaceView getGLView()
public void cameraPreviewStarted(int width, int height, int rate, int cameraIndex, boolean cameraIsFrontFacing)
CameraEventListener
cameraPreviewStarted
in interface CameraEventListener
width
- The width of the video image in pixels.height
- The height of the video image in pixels.rate
- The capture rate in frames per second.cameraIndex
- Zero-based index of the camera in use. If only one camera is present, will be 0.cameraIsFrontFacing
- false if camera is rear-facing (the default) or true if camera is facing toward the user.public void cameraPreviewFrame(byte[] frame)
CameraEventListener
cameraPreviewFrame
in interface CameraEventListener
frame
- A byte array from the camera, in the camera's capture format.public void onFrameProcessed()
public void cameraPreviewStopped()
CameraEventListener
cameraPreviewStopped
in interface CameraEventListener
protected void showInfo()


Get in touch: emailcehager<at>gmail<dot>com | linkedin | twitter | github
navigationProjects
hashography
Web Application
Hashography visualizes how users are tweeting about certain words in real time, around the world. Written entirely in Javascript, it utilizes the Twitter and Google Maps API, Node.js, and Socket.io.
- - 8 day final student project completed at Dev Bootcamp
- - Completed using the Agile methodology
- - Deployed to Heroku
Curious Appetite Travel
Website Refresh
Travel company in Italy. The owner requested a complete rehaul of website design and structure, including custom coding of particular features.
- - Designed using Squarespace
- - Custom CSS and JavaScript added to enhance look and functionality
-Inital-
coffee&tea
Web Game
Word game adapted as a web application. Built with Javascript, Node.js, and MaterializeCSS.
- - Over the weekend student project
- - Deployed to Heroku
North Rim Country Store
Website Refresh
Small country store at the North Rim of the Grand Canyon. Their existing website needed a refresh, to streamline, simplify, and lighten up the current design.
- - Designed with the Joomla CMS framework, and hosted on HostGator
BloomingForest
Web Application
Polling app designed to allow users to view polls by category and vote on them, as well as create anonymous polls. Launched using Sinatra, PostreSQL, and the Highcharts API.
- - 2 day student project, designed as an introduction to making a fully functioning web app
- - Deployed to Heroku
GameShelf
Web Application
An application designed to manage one’s board game collection providing support for friend lists (as well as listing what games friends own), game search, and game information pages with comment support. Built with Materialize, Rails, and PostgreSQL.
- - 3 day student project, designed as an introduction to working for a 'client'
- - First employ of the Agile methodology to complete a group project
- - Deployed to Heroku
Git Cheat Sheet
Web Reference Guide
Online git quick reference guide. Written with HTML5 and CSS3.
- - Student project completed in remote collaboration via Hangouts sessions.
- - Introductory web design collaboration project.