Hi,

It’s a busy summer ahead with events, SPC Certifications, and the release of SAFe 2.5 (see post). so I thought I’d take a moment to let you know my personal, public schedule for summer and fall:

• June 10-11 & 13 ,  SAFe Certification in Berlin (Sold Out)
• June 12: Keynote: Berlin ScrumDay, 1:00 PM  June 12. (http://www.scrum-day.de)
• June 15: Keynote: DARE conference in Antwerp, Belgium
• July 10: Keynote: Scaling Agile Leadership Summit in Atlanta with Rally Software
• July 30-Aug 2: SAFe SPC Certification in Boulder, CO (seats  available)
• August 6, (2 PM) Talk:Agile 2013 in Nashville. Be Agile. Scale Up. Stay Lean. (I’ll be there most of that week)
• September 24-27, 2013:  SAFe SPC Certification with Al Shalloway in Seattle, WA. (seats  available)
• October 7-8&11: SAFe SPC Certification in London, UK. (event not yet open for registration)
• October 10: Keynote: Agile Business London
• November 4-5&8:  SAFe SPC Certification in Tallin, Estonia
• November 11: Keynote: Helsinki Agile Conference (event not yet open)

In addition, others one our team will be delivering regional certification events as well, including SPC certifications in the US, and planned for Australia and China for fall. Stay tuned to http://www.scaledagileacademy.com/events/event_list.asp.

In double addition, our partners are now delivering Leading SAFe courses around the world (20 events and locations this summer). You can find a course near you at: http://www.scaledagileacademy.com/events/event_list.asp.

 

Here is my near term  schedule for SAFe certification and public speaking events:

• June 10-11 & 13 ,  SAFe Certification in Berlin (Sold Out)
• June 12: Keynote: Berlin ScrumDay Keynote 1:00 PM  June 12. (http://www.scrum-day.de)
• June 15: Keynote: DARE conference in Antwerp, Belgium
• July 10: Keynote: Scaling Agile Leadership Summit in Atlanta with Rally Software
• July 30-Aug 2: SAFe SPC Certification in Boulder, CO (seats  available)
• August 6, (2 PM) Talk: Agile 2013 in Nashville. Be Agile. Scale Up. Stay Lean. (I’ll be at the conference most of that week)
• September 24-27, 2013:  SAFe SPC Certification with Al Shalloway in Seattle, WA. (seats  available)
• October 7-8&11: SAFe SPC Certification in London, UK. (event not yet open for registration)
• October 10: Keynote: Agile Business London
• November 4-5&8:  SAFe SPC Certification in Tallin, Estonia
• November 11: Keynote: Helsinki Agile Conference (event not yet open)

How do we suggest that managers …well… manage self-organizing teams?  By self-organizing, we also mean self-managing.

Let’s assume that not all ‘self-organizing teams’ will self-organize effectively.

So, a few suggestions.

1. Get rid of almost all the old stuff.

Really.

Maybe keep one or two ‘group’ meetings at fairly long intervals, eg, once a month. (We are assuming that the Sprint meetings will give them and you most of the information you all need.)

2. Offer to give the teams feedback.

Get reasonable information from the Scrum teams. Information that they already have.  Discuss with them how you are looking at overall success.  Go to the main meetings. Offer to discuss.  Offer to give feedback.  But don’t force yourself on them.

2b. Overall success

Of course managers should be involved in defining overall success for a team. The basic mission and the key constraints.

I would typically recommend a focus on business value and velocity.  By velocity, we always have to say “We don’t want you working more than 40 hours per week, but we want the overall velocity of the team to double. By removing impediments, not by working harder.”  And focus on quality. Always, it needs to be higher.

Measuring BV success is hard, but important.  (Much more to say, but not here, now.)

In general, business managers should be defining what BV is.  What BV means for a specific team.  Not technology managers.  Ceteris paribus.  (Other things equal.)

3. Offer to fix impediments.

Offer to help. Or approve money, or other people, or just help get permission.

Offer once each Sprint, at least.

4. Group yourselves in small teams (of managers).

We think managing Scrum teams doing innovation is very hard.  The problems each team is trying to address are usually quite hard.  The dynamics inside a team are complex. Etc. Etc. It is a problem (or set of problems) where we need multiple heads to consult.

So, I recommend that 3 managers group themselves, and manage 5-7 teams together. And consult with each other about how to help the teams be more successful.

As implied by my prior comments, at least one of these managers should be a business manager.  Someone who looks at things mainly through a BV lens.

5. Impediment Removal Team

I recommend managers form an “impediment removal team” (IRT).  And that the managers take impediments from the teams, and work on them, one at a time. And deliver ‘fixes’.

Discuss with the team when the IRT will take impediments, and when the impediments will ‘stay’ with the team.

6. After some time, intervene if the team is failing.

“After some time” is the hard part.  How long to wait?  How much do you say?  When?  How?

First, let me suggest that if you smell problems, ask the Team.  And ask them if they want help.

Do not look only at the ‘leaders’ in the team (eg, the PO and the SM).  Ask the whole team.  Remind them that they are all responsible for success.

In some cases, the team or the situation can be quite messed up. You just must intervene.  But usually they should at least have told you the problems (the impediments) and you should be agreeing.  And usually, depending on the nature of the impediment, you have given the team a reasonable opportunity to address the impediment themselves, their way.

And your action (as a small team of managers) could be selected from a very broad range, depending on the nature of the situation.

You could cancel the effort.
You could disband the team.
You could add or subtract a person.
You could some people more highly dedicated.
You could help them get better Continuous Integation and better automated testing.
You could help them improve the Agile Specs getting into the Team (just enough, just in time, documentation).
You could get a more specific impediment fixed. In possibly lots of different categories.

Does this make the manager’s job more specific?

For those SPCs and others who have been working directly with the Scaled Agile Framework, it will come as no surprise that the next update – V2.5 – is imminent. Indeed, many of you have contributed to the new concepts, including a few of you who were directly involved in redesigning that gnarly release-planning-flow thing. In addition, we’ve struggled over time with communicating the Develop on Cadence, Deliver on Demand message, that is not so obvious from the 2.1 Big Picture, so we’ve had dozens of variants for that in flight as well.

In any case, we have finally converged on a new design and icon/objects for V 2.5, and we are releasing it here in a staging area for SPC and customer preview. It is incomplete, but communicates better than the existing model, so we are releasing it here scaledagileframework.com/BP25 incrementally, including linking a number of new articles to new BP objects/icons. Many new articles are yet to be developed.

SAFe 2.5 Big Picture Preview

 

There are two new major graphic/communication elements.

1. The new release planning flow. The yellow down and up bars, resulting in both Team PSI Objectives and Program PSI objectives. That was always true, but not very explained very well in the conflated “Objectives” object.

2. New treatment for Develop on Cadence. Deliver on Demand, now with “green means go tips”, not just at the PSI boundaries, but whenever the system has potentially releasable conceptual integrity.

There are 6 new objects:

1. Business Owners. Linked to draft article.

2. Sprint goals. Linked to draft article.

3. Value Streams. Linked to draft article.

4. Deployment Operations. WIP; not released yet

5. Team and Program PSI Objectives. WIP; not released yet.

6. Sprint Execution. WIP; not released yet.

The Plan

And here’s the plan:

• Update Courseware end of July
• Finalize and push new BP Aug 1, 2013 (may have some articles in Abstract form initially)
• Announce at Agile 2013.

….. then complete any missing article details as quickly as possible, if not already done.

 

 

I’ve done storymapping many times over the years, and Jeff Patton’s article is a great source for the fundamentals.  I always prefer to start with a few people to build the initial map.  But we had product owners, UX designers, coaches, and technical account managers all talking to customers in a new problem space, and they all wanted a say in what we build.  

So when my colleague Stephen asked me to help facilitate a meeting to talk about what we should build in that new problem space, I tried to get him to keep it to about four people.

Stephen wanted to include everyone who wanted a say, so he sent out an invite to 15.  Only 8 accepted, so I figured I’d just split into two groups of four and they’d work on different parts of the map.

But that morning, all 15 people showed up.  I had to improvise, but with some quick thinking, I was able to make it work and go from 15 different opinions to a prioritized list of user tasks.  Here’s how we did it.

1. We started with personas.  We have a standard set of a dozen or so that we use across key products.  We reviewed them with the group.  Then I split them into three groups: four people who had recently visited customer A, 4 people who had visited customer B, and 4 people who had spent time with several other customers.  I asked each group to think about the people they had encountered on their visits who were working in the problem space we were exploring.  I asked them to write those people’s names on purple index cards along with the persona they represented.

We read out from each group, and I set the purple cards on the matching persona sheets.  We then had a large group conversation about whether there were clusters of related personas who seemed to be working on similar activities from similar perspectives.  Turns out, we had 3 clusters of personas who basically approached the problem space in similar ways. All of this took about an hour.

2. After a 10 minute break, I asked people to split into 3 groups of 4-5 to focus on those clusters.  I gave each group exactly 5 blue index cards, and then gave them 7 minutes to identify the top 5 activities that their personas needed to do in the problem space.

(Why exactly 5 cards?  I didn’t want too many items at too fine a granularity. 5 seemed to be a good starting point.  I was ready with spare cards but nobody asked for them.)

After 7 minutes, one group had 5 perfect activities, another group had no activities written down, and the third group had found some sneaky blue sticky notes that almost matched the color of the index cards - they were debating 9 options.  (You can see another Steve in this group in the bottom of the photo above).  

To break the logjams, I rotated 1 person out of each group and gave them another 5 minutes to finish the top five user activities.  We did a quick readout from each group, and then I rotated another person out (so each group had 2 original members and 2 new members).  

3. With the newly mixed groups, I gave each a big pile of yellow stickies and asked them to break their activities into user tasks - specifically tasks where the personas were substantially blocked in their activity and we felt we could make a big difference with software.  I gave them 15 minutes for this.  

4. Then I asked each group to choose a spokesperson to stay behind, and 3 people to move to another group, listen to the presentation, and provide feedback.  Each participant got 2 sticker dots to vote on the tasks they thought represented the best opportunities for us in the problem space.  

 

5. I repeated this for the other remaining group, and did a final 5-minute chance for the spokespeople to also see and vote on the other clusters.

6. Now, I reformed the original groups from step 3.  I asked them to order the yellow cards, best opportunities highest, using the dots as an input.

7. I gave the groups 90 seconds to choose their number 1 task for each persona cluster.  The results were read out to much cheering from other participants.  We repeated - another 90 seconds to choose number 2, and 90 seconds to choose number 3.  (This tight timebox worked out because we had been discussing the work for several hours and we just needed to push for a decision.)

Presto! In just a couple of hours, 15 strong-willed and well-informed people were in agreement about our top priorities in a new and complex problem space.

I’d love to answer clarifying questions in the comments about the details of running this kind of activity.

 

Alex Pukinskis

Something I wish I had read years ago (or found out about) is this nice concise list of resources around distributed systems:

http://dancres.org/reading_list.html

When I started having issues around 2PC, and twitter was being beyond unhelpful with pointers to actual resources, this list of papers did way more than random internet searching did. One of the more frustrating things about the distributed systems community is that the writings are…well…distributed. You don’t know what questions to ask or even what to begin looking for. This list at least provides a great start.

And for ongoing information, the high scalability blog is also a nice resource. Hopefully this helps the next person with scale problems out!

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

A very effective learning that has come out of many fields of research is that we function well in small groups, specifically groups that range from five to seven people in total. Scrum allows for a slight expansion of that range up to twelve people.  This allows for enough people to be together to discuss issues and solve complex software problems with a diversity of skills and experience.  As well as avoiding the problem of having too many people that the lines of communication become overwhelming.  If the Scrum Team is only four people, then that means that you only have two people doing the tasks in the Sprint Backlog (since the others are the ScrumMaster and the Product Owner). If the team is thirteen or more people then trying to discuss issues, having a focused Daily Scrum meeting, and even building an effective Scrum Team becomes that much harder.  The larger the team, the longer it takes to get to a high-performance state.

Open Space is a usual traditional the XP2013 or (XP20xx series of conferences). I proposed a session around what makes an Effective Tech Lead because last year we had a great discussion and it was a great opportunity to explore the space with other people either trying to understand the role more, or just interested in the discussion.

We tried to capture the results on the board below as much as we could:

For those of you who have been managing and growing agile teams for some months, see if the following sequence of graphs doesn’t ring a bell:

Exhibit A: The Early Signs of Myopia

This depicts a time-lapse illustration of a typical agile team performance over, say, six to nine months.  By performance, I mean level of team innovation, enthusiasm, productivity and stakeholder engagement.

The phenomenon depicted shows a team that starts off all great guns. Then over time, continuous improvement, reflective action, performance and overall enthusiasm begin to level off. Finally, those levels begin to fall.

What’s Happening Here?

Well, what’s happened is that this agile team has found itself bumping up against significant institutional blocks. Existing rules, structures and processes slow things down. Managers who haven’t yet learned how to facilitate self-organizing teams block, in subtle and often unintentional ways, team progress. Lack of genuine customer engagement leaves the team focusing on increasingly tactical issues. Political forces are too often aligned around the us-versus-them mindset that often accompanies any kind of potentially successful organizational change. In short, this team (like so many others) has hit an institutional ceiling:

Unfortunately, an all-too-common management response is to try to get teams to work harder. Teams are asked to work evenings, weekends, to cut corners—to do anything and everything to meet the deadlines. This leads to burnout, further drop in quality, missed sprint goals, and loss of focus. In the end, you undermine the practices and the discipline that are the source of your salvation.

Or managers try to find ways to motivate teams, or they try this-or-that to try to re-inject that original energy. All to no avail.

A More Holistic View of Your Organizational Setting 

The simple—or perhaps not-so-simple—fact is that if it is to be sustainable, effective agile practice must move beyond the agile team and address the broader organization.

The above picture portrays an organization as a spectrum of performance capabilities—things that organizations are capable of doing. These capabilities are depicted as five spectral bands. In this spectrum view, each band represents an aspect of organizational performance.

• The Execution band refers to the day-to-day, moment-by-moment practices by which work gets done. We usually think of execution in terms of software teams and, as such, includes development and engineering practices (e.g. configuration management, testing, design, programming, integration, etc.) as well as other activities such as requirements validation (e.g. user stories) and release planning (e.g. story point estimation).

• The Delivery band refers to the practices by which executed work is delivered to stakeholders. This can include how product delivery is managed (e.g., as projects), how requirements are established and shared with a delivery team, and even how portfolios of product deliverables are managed and delivered. This realm of performance typically falls under the name project management.

• The Product/Business Strategy band refers to how products are envisioned, how they reflect and help to realize broader business goals and strategies, and the degree to which they elicit profound customer engagement, whoever the customer happens to be. It also refers to an organization’s capacity for what Clayton Christensen refers to as disruptive innovation–the capacity to introduce innovations that redefine the broader market space in which a company’s product falls. This capability is most commonly captured with the term program management.

• The Organization band refers to the organizational structures, processes, and systems that determine how work gets accomplished in the broadest sense. This includes things like performance management, governance, regulatory compliance, reporting structure (who reports to whom), approval processes, budgeting, and so on. What does it take to get things done? What obstacles do people run into when trying to get work done effectively and efficiently? These are the kinds of questions that are addressed within the organization band.

• The Leadership band refers to the ways in which managers and leaders—at all levels of the organization—manage and lead. Do leaders tend to rely heavily on directive, command-control leadership approaches? Are people encouraged to take ownership, and hence greater risks? Or are they encouraged to look upwards, managerially, for direction and permission to take action? Are leaders able to see the larger picture, the greater complexity? Or is their frame of reference narrow and overly simplifying, resulting in management strategies that are ultimately debilitating and ineffective?

Myopic Agility

The problem is that most companies focus all of their energy and attention on one or, at most, two of these bands—They practice myopic agility. There are a number of forms which myopic agility can take:

Delivery Myopia

One of the most common forms of myopic agility is maintaining sole focus on agile team delivery (the delivery band), while ignoring the other bands.

With this form of myopia, agile teams are doing (or trying to do) some specific practice, such as Scrum. They go through all the right motions, such as doing sprint planning meetings, stand-ups, reviews, and retrospectives. However, their engineering practices are not very agile. Neither is their product strategy.  Meanwhile teams run into all kinds of organizational and technical hurdles. After a while, teams cannot deliver stories, their quality deteriorates, and the lack of alignment with product management begins to sour relations. Before you know it, you are beginning to think that the old way may have been better.

 

Team Myopia

Another very common form of myopia is team myopia.

Here, we’re a little better off, because at least now we have engineering (Execution band) practices on board, so delivery is a little smoother, and overall quality is higher. However, at some point the team becomes adrift in terms of delivering value to product management. Or, product goals are constantly shifting, causing churn and constant rework for the team. Meanwhile, teams run into the kinds of organizational and leadership challenges they run into under delivery myopia. Though less obvious than delivery myopia, team myopia will eventually undermine the team’s efforts.

Product Myopia

As Lean Startup continues to gain a greater foothold in the industry, we are seeing more and more of this kind of myopia. Teams are trying to implement practices of Lean Startup (the product/business strategy band), without dedicated delivery teams (the delivery band), without solid engineering practices (the execution band), and without proper organizational or management support (the organization and leadership bands).

In the end, these efforts are not producing the results they could. That’s because even the best—the most lean, the most adaptive, the most emergent—Product strategy can’t be concretely realized without effective delivery (and execution); even if there is a reasonable level of leadership and organization-level agility.

Organization Myopia

You’ve probably seen examples of management interventions, such as TQM, Six Sigma, reengineering—all of which share a lack of rigorous support along the other bands. Or, you’ve been a part of classic organization development (OD) efforts that fail to stick due to inattentiveness on the product, delivery and execution fronts.

All of these are forms of organization myopia.

Leadership Myopia

Finally, there is the decades-long focus on leadership. Hundreds of leadership books are published each year. Many of these offer effective practices to improve leadership capability, such as the work of Chris Argyris, Bill Torbert and, more recently, Bill Joiner.

It is our belief, however, that such practices are best supported when similarly concrete practices are brought to bear across other aspects of organizational performance–as for instance, in the areas of product management, product delivery, technical practices, and organizational structures and culture. I’d like to suggest that sustainable leader development is buffeted, and the adaptive initiatives of leaders supported when similarly adaptive and agile practices are brought to bear across the other bands of organizational performance.

From Myopic Agility to Organizational Agility

The fundamental problem with myopic agility—regardless of the target performance bands—is that even if all you say you care about is that single band (“we only care about team delivery,” “we only care about our product experiments,” etc.), your likelihood for sustained success is determined by the degree to which you are able to achieve congruent agile performance across the other bands.

At BigVisible, we advocate a holistic approach to building agility. Our target goes beyond team agility. Our target is organizational agility.

Organizational agility refers, in the broadest sense, to an organization’s ability to effectively sense and rapidly respond to change and complexity in ways that increase that organization’s capacity to thrive, all-the-while remaining true to its highest aspirations.

Taking a broader, organizational approach to agility recognizes the inherent mutual synergy of all five aspects of organizational performance.

Conclusion

Organizational performance is holistic: the bands are interconnected.  You can survive for a while with myopia, but at some point your near-sightedness will need to be corrected if you are to avoid crashing.

We will continue this conversation in a near-future blog article. In the meantime, you might want to read an article by my colleague George Schlitz that outlines an holistic approach to agility.

You can also download my white paper, which goes into more depth about strategies and design for organizational agility.

The post Organizational Agility & the Dangers of Myopic Agility appeared first on BigVisible Solutions.

http://www.selfishprogramming.com/2013/06/06/happy-birthday-to-agile-adventures/

Portia has just announced that her book, The Dream Team Nightmare, will soon be published - in bits and atoms - by The Pragrmatic Press.

Nice!

One frequently asked question for hardware or embedded projects considering Scrum is, "How can we get stuff done every sprint? It takes longer to develop a piece of hardware than could ever fit in a two-week sprint!" Hardware development needs to take a slightly different view on iterations and iterating than software development.

When the WIKISPEED engineers were first working on the interior, they realized that the lack of an emergency brake was slowing down their progress. The brake handle sits between the seats, close to the gearshift and to the attach points for the seats and seat belts. Because no one knew what the emergency brake handle looked like, they were unwilling to commit to design decisions on these nearby components.

The solution was "version 0.01" of the emergency brake: a cardboard box that said, “the brake handle will fit in this box.” That was enough functionality that the team could move forward on nearby components, even though nobody had any illusions that this cardboard box would actually hold the car in place!

When working with hardware, you will iterate on your designs:

1. Create the test that your design should pass.
2. Create the simplest design possible that enables the test to pass.
3. Improve the design to be simpler or more elegant.
4. Repeat this process ("Iterate on the design") until improving this component is no longer the highest value work you can do.

In the case of v0.01 of the emergency brake, the acceptance test was "Can the engineers design the surrounding components with confidence?" The cardboard box satisfied this test. Other components were judged to be of higher value, so they stayed with the cardboard box until the other components were finished enough.

When developing software with Agile, each iteration should produce potentially deliverable functionality. That may not be possible when working with hardware, so you may need to iterate on a particular item many times before the design is satisfactory. In the case of the WIKISPEED X-Prize entrant, those subsequent iterations included, "An emergency brake to hold the car in place," and "An emergency brake which produces no resistance when the car is in motion."

You may also need to iterate on your acceptance tests, especially as you strive to automate them. Before WIKISPEED performed a real crash test, they had done many Finite Element simulations. These are cheap and repeatable, because all they need is computer time. Then they had a real crash test performed. That crash produced results that were different from their simulation, so they iterated. They used the real crash data to improve their simulation. Eventually their simulations became close enough to reality that they no longer needed the expensive physical tests.

Next: Hardware Design Patterns

Today's tester role is more versatile and calls on a wide range of skills. Now testers have tasks throughout the sprint, and they also program yes! as regular programmers. (I don't say as developers, as all participants in the team...

In my continued reading of Daniel Kahneman’s Thinking Fast and Slow I’ve reached the section which talks about the affect heuristic which seems particularly applicable to the technical decisions that we make.

The dominance of conclusions over arguments is most pronounced where emotions are involved. The psychologist Paul Slovic has proposed an affect heuristic in which people let their likes and dislikes determine their beliefs about the world.

The way I’ve seen this heuristic coming into play in the software world is when we do an ‘objective’ overview of the technical tools/options that we could use to solve a particular problem.

We may do this by coming up with a list of advantages/disadvantages for each technology but the way we come up with this will probably be influenced by which of the technologies we prefer.

We’ll therefore place strong emphasis on the advantages of a technology and not think too much of disadvantages or work arounds that we have to implement.

For example if Clojure were the technology in question then as an advocate of Clojure you might focus on the reduced lines of code and benefits of the functional way of programming and place less emphasis on the learning curve that new team members will have to overcome.

Equally if you weren’t a fan of Clojure then you’d do the opposite.

I covered similar ground in a post I wrote a few months ago about compatible opinions where I suggested people used confirmation bias to back up their own opinions.

I think the affect heuristic is slightly different though because it applies even when we think we’re being impartial in our judgement.

When I read things I like to try and think what action I should be taking as a result of learning new information. In this case I think the take away is to be more self aware than usual when talking about things we’re passionate about.

One way to achieve that could be to run our opinions via someone who is knowledgeable in the subject area but is less emotionally involved.

It’d be interesting to see whether this resonates with others as well and how you handle it.

Scott Turnquest

To help us better understand how our release process has evolved over time, the Go product manager Marco, created the following video and shared it with us. I thought it was a fun way to see how our process has changed over time:

Thumbnail: 

read more

Surprise!

The first ever Agile Adventure “The Dream Team Nightmare” is one year old today!

It’s a Choose-Your-Own-Adventure where you, the protagonist, get to play the role of Agile Coach and help out The Dream Team who are in deep trouble. Your choices steer the story and determine the outcome for the team.

About the Book

The book was self-published last year. Since then, it’s had more than 600 downloads.

To find out more about the book, visit Leanpub.com.

To find out more about the story behind the writing of the book, click here.

Last Chance to Own the First e-book Edition

The good news is that you can still get hold of the original version from Leanpub.com for a nightmarishly reasonable $6.66.

Or you can buy it as part of a great Agile bundle of books for $50 instead of the recommended price of $142.61.

But not for much longer. That’s because The Pragmatic Programmers and I are busy having fun producing the next edition which will exist as both an e-book and in hard copy. Yaay!

The objective of an agile development team is to regularly release high-quality software so new features can be introduced and feedback collected. The goals of a traditional operations team are often in direct opposition as they focus on stability and uptime usually by seeking to minimize change. At a startup where the operations and development [...]

Linda Rising shares influence strategies that you can use to more effectively convince others to see things your way. You’ve tried and tried to convince people of your position. You’ve laid out your logical arguments on impressive PowerPoint slides—but you are still not able to sway them. Cognitive scientists understand that the approach you are taking is rarely successful. Often you must speak to others’ subconscious motivators rather than their rational, analytic side. These strategies take advantage of a number of hardwired traits: * “liking” — we like people who are like ...

We moved to the new office about 3 months ago. With the office moves, it’s usually very uncomfortable to break away from the cozy nest in the familiar space and trade it for the uncertainty of a new office. But then it’s getting better, one good thing pulls another good thing, and you like the new environment more and more.

My starting “like” point about the new office were the circular-shaped walls. They reminded me of the medieval castles romanticism, and that was enough for a start. Then I discovered that the round walls are not only about the ethereal romanticism. They have some practical purpose, and they do hold a harmonious creative space. It feels much better working in the rounded space than in the rectangular one. Try it some day, if you get a chance, and you’ll see what I mean.

What is it about those round walls that makes them that special, anyway? In spring, when we just moved in, the sun was moving along the lower ecliptic, and the first spring rays were more welcomed, than hated, because everyone likes the warmth of the sun after cold winters.  Then, closer to summer, the sun’s trajectory in the sky got higher, and the circular shape of the building made it harder for the scorching heat to get inside. I’m not sure if the architects were aware of the feng shui guiding principle that the circular wall shapes are more harmonious for the well-being and creative energy than the rectangular walls, but there’s one thing I know for sure. The architects must have had some hard times reconciling their vision with the construction team, as in terms of construction, it’s harder to build a circular-shaped high tower. Construction guys generally do not like the round shapes. They hate them. If you tell a construction engineer that he would have to deal with anything circular (I remember the sour face of the guy who did the renovations for my apartment when he saw the rounded corners :), it means you give them more headache, and they will try to avoid this headache by all means. They’re looking at construction projects not with the eyes of people who are supposed to feel good working or living in this environment. Construction engineers focus on the pains this will bring in to their work. Like, how do they implement the supports, how do they have them stabilized in place, etc.

If you’ve been involved in designing and/or implementing a software system, you might have had a similar experience. Software developers switch to this engineering-only mode as they get absorbed in their technical meetings and forget that the prerogative (at least, the high-level prerogative before even discussing the duration and costs of the implementation) is the joy of experience and uninterrupted flow when using the software.

Here’s an example: database-related decisions. It’s very annoying  for users to experience the delayed load times, but there can be some intrinsic reasons that make developers ignore this inconvenience. Well, the difference is obvious. Software systems generally do not have such long lives as buildings. Stakeholders have to weigh the odds of spending more time to optimize database load times with their considerations for the future. Meaning, what if they have in mind the newer and the better version of the same system? It makes no sense then to hone the old system that would be sunset soon. But we still need to keep the awareness, as we engineer software solutions, that software systems are for people. It does take some decision-making skills to find the balance between the human-related part and the programming-related part, and it’s not even about the usual programmers vs. designers holy war.

For any system you’re developing, or designing, keep in mind the round walls of UX. Your solution needs to accommodate them, because if people like a building, or a software system, they will be delighted to spend more of their time with it (or in it). Yes, the development costs might be higher, and it might take more time. But if people like what you’ve done for them, if they feel comfortable and harmonious in the figurative round walls feng shui of your software , they’re more likely to become your devoted customers and bring along still more.

 

 

One of the comments in my last post on message idempotency asked about message ordering. This is part of a larger issue that I’ve run into recently around turning two-phase commits off.

When looking at mutating state through interactions, typically we take the approach of:

1. Receiving messages to change state
2. Applying state changes and discarding the message

Those in the event sourcing world see the problems of this – it’s really hard to reconstruct the series of activities that led to the current state when all you have is the final picture. You can make an educated guess on how we got here, but that’s it. We have to be crime scene detectives, imagining scenarios that led to our current situation.

It’s this central state that can become a bottleneck. If two people are trying to affect change to the same entity at the same time, how can we effectively allow this to happen? We can look at concurrency models (moving from pure ACID in a Serializable isolation to a relaxed, Snapshot isolation), but that is still a preventative mode.

What if we did away with the need to lock anything? This is where switching to a different mode of thinking. That’s where ACID 2.0 comes into play.

ACID 2.0

ACID 2.0, explained in detail by Hohpe and expanded on by Helland, focuses on achieving high throughput by altering our data model Our data model now exhibits the following characteristics in its interactions:

• A – Associative
• C – Commutative
• I – Idempotent
• D – Distributed

For our system, we are little “d” distributed in that we have multiple processes handling requests, but not multiple nodes in our database. We’re still on a big relational box, but we have change our model slightly.

In our system, we process daily transactions from point-of-sale systems from a nationwide retail chain for a loyalty program. You buy things and earn points. If you earn a coupon, you are deducted points.

Originally, we modeled this system with a list of transactions and a single balance:

• Spend $10, balance now $10
• Spent $50, balance now $60
• Spend $75, balance now $135. Hit threshold, give coupon, balance now $35

That works decently for a reasonable throughput. It tends to fall down with higher throughput, because any operation has to both record the item and update the balance. Issuing coupons is a rather expensive operation, further decreasing throughput. Order mattered, too, as we couldn’t let the running balance ever be “wrong”.

In order to achieve higher throughput, we simply needed to model our system differently. We instead modeled these interactions as a ledger:

Txn ID Date Type Amt 1234 2/1/2012 Spend $10 4321 2/2/2012 Spend $50 5345 2/10/2012 Spend $75 0989 2/11/2012 Coupon ($100)

We have two basic operations on our model: Spend and Coupon. One is a debit and one is a credit. The nice thing about the above model is it can easily fit in our ACID 2.0 constraints:

• Associative & commutative – No matter what order we sum up the amounts, the final balance is the same
• Idempotent – we only record a transaction if we know we haven’t seen that transaction ID before

In our original model, we would check the balance constantly to see if we needed to give out a coupon. In our new model, we separated that piece out into a separate process:

• Process 1: Record transactions from yesterday
• Process 2: On a periodic basis, search for accounts due a coupon, and give them one (by deducting the amount)

Because only a fraction of those daily transactions needed to get coupons, separating that piece out into a separate process ensured that the recording of spend went as fast as possible. It wouldn’t get slowed down by handing out coupons.

We did have to do work to ensure that we didn’t double-issue spend, so in those cases, we would employ various concurrency schemes to ensure that no two people were issuing coupons to the same ledger at the same time. Importantly, we didn’t care if someone was recording spend, since if we missed you this time, we’d get you the next time.

By slightly changing our modeling approach and thinking in terms of operations that could be applied in any order, we eliminated our original self-inflicted wounds of requiring ourselves to have always-consistent derived state (the balance). And in doing so, we saw our throughput shoot through the roof.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.