Skip to content

Blogs

A look at Six Years of Blogging Stats

Agile Complexification Inverter - Sun, 02/19/2017 - 05:09
What do you get from six years of blogging about Agile/Scrum and your continued learning experiences?

Stats from Agile Complexification Inverter blog site

Well the stats are just one insignificant measure of what one gets from writing about their experience.

The bad artist imitate, the great artist steal.The more meaningful measures have been seeing some of these articles and resources put into practice by other colleagues, discussion that have happened (off line & sometimes in comments or twitter, etc.) with readers that require me to refine my thinking and messaging of my thinking.  Interestingly some times seeing a resource that you have created being "borrowed" and used in another persons or companies artifact without attribution is both rewarding and a bit infuriating.  I like that the concept has resonated well with someone else and they have gone to the trouble of borrowing the concept, and repeating or improving or repurposing the concept.

Let me borrow someone else's concept:  "The Bad Artist Imitate, the GREAT Artists Steal." -- Banksy


Most of all the collection of articles are a repository of resources that I do not need to carry around in my 3-4 lbs of white & grey matter.  I can off-load the storage of concepts, research pointers and questions to a semi-perminate storage.  This is a great benefit.

Categories: Blogs

Book Review: The Wisdom of Teams

Agile Complexification Inverter - Sun, 02/19/2017 - 05:09


Introduction:  What We Have Learned
Originally written in 1993, this edition written in 2003 has additional insights from 10 years of working with teams.  The authors see more pragmatism on the subject, less thoughtless rushes to a fad movement.  Top leaders are seeing that teams also apply to themselves, at the top of the business.  They see the core aspect as discipline, not the management fad du jour.  The discipline for team performance has 6 basics: team size, complementary skills, common purpose, performance goals, commonly working agreements, and mutual accountability.  The desire to be a team is not sufficient - one must have performance centric outcomes as the objective.  Leadership is more important at the beginning - but not the primary determinant of success.  Most organizations have untapped potential in team performance.  The organizations performance ethic makes the difference between one-off success and widespread organizational team performances.
The authors develop an explicit terminology, to distinguish commonly misunderstood phrases when discussing groups and teams.  The Y-Chart (p. XXI) helps explain the taxonomy of groups (Effective Group vs Performance Units; Single-Leader Unit vs Real Team).  They define an abstract Team Performance Curve, noting time as the major factor in achieving high (extra-ordinary) performance.  The decision of which type of team; single-leader unit vs team is dependent upon 3 factors: need for collective work products integrated in real time by two or more people, shifting leadership roles for situational awareness, need for mutual accountability in addition to individual accountability.  Setting outcome-based goals is essential to achieving high performance (as apposed to activity-based goals).  Real teams require more time and leadership capacity than single-leader units.  Process support for multiple team opportunities across broad programs is essential to scale the team success from one-to-many.
Prologue:  A Note About What to Expect
The book notes the obvious concepts but also the subtle nature of language used to describe the concepts are required to be precise in defining the discipline.  The authors find that it is difficult to apply common sense to teams.  Expect failure when: building the team for its own sake is the goal (rather that demanding performance challenges), the discipline of “team basics” is overlooked, many areas for teams are left unexplored in organizations (teams: recommend things, do things, run things), teams at the top of organizations are the most difficult, individual accountability is the norm (as apposed to team/group accountability).
Uncommon-sense findings: strong performance standards seem to spawn more teams than teaming-for teaming sake; high-performance teams are extremely rare; hierarchy and teams go together well; teams naturally integrate performance and learning; “teams are the primary unit of performance for increasing numbers of organizations” (p. 5).
Part One:  Understanding Teams
Focusing on Team Basics - figure 1-1 (p. 8)
Apex:  Performance Results; Collective Work products; Personal GrowthSides:  Skills (Performance results - Collective work products) Accountability ( Performance results - Personal growth) Commitment ( Collective work product - Personal growth)Internal:  Skills - Problem solving, technical function, interpersonal Accountability - Mutual, team size, individual Commitment - Specific goals, common approach, meaningful purpose
Chapter 1:  Why Teams?
The authors have learned that although many executives understood the argument for using teams many didn’t extract the real potential from the teams or the opportunities to use teams.  Many times because of unwarranted assumptions and poor knowledge.Key lessons:
  • “Significant performance challenges energize teams regardless of where they are in an organization.”  Performance is the primary objective.  A team is the means - not the end.
  • “Organizational leaders can foster team performance best by building a strong performance ethic rather than by establishing a ream-promoting environment alone.”  Focus on customer satisfaction performance rather than teamwork performance.
  • “Biases toward individualism exist but need not get in the way of team performance.”  Turn individualism, self-preservation, and self-centered objectives to the benefit of the team.
  • “Discipline - both within the team and across the organization - creates the conditions for team performance.”  “Groups become teams through disciplined action.  They shape a common purpose, agree on performance goals, define a common working approach, develop high levels of complementary skills, and hold themselves mutually accountable for results.”

Teams are made up of individuals with complementary skills - build on strengths, not to cover weakness.  Define clear goals, via team communication. Build real-time problem solving skills and initiative, allow adaptive behavior.  Provide social dimension to enhance work - teams fundamental nature are people interactions.  Fun is part and parcel of the process - encourage it.
Resistance to teams come from 3 primary concerns: ”lack of conviction”, “personal discomfort and risk”, and “weak organization performance ethics” (p 21-23). 
Teams do not solve all problems, they are not the answer to every problem.  They require discipline and practice.  Organization culture may be opposed to teams if a strong individualistic performance is reward in spite of team performance.
Chapter 2:  One Team: A Story of Performance
As a basic unit of performance a team blends the knowledges, skills and abilities of several people strengthening the overall performance of individuals.  Many people having once experienced the power of a high performing team long for the experience again.  Burlington Northern launched the Intermodal Rail era after deregulation in 1981.  Largely the result of a core team of 7 individuals, with an extend group of 45 people.  This team was largely self selective, all were interested in the new prospects of intermodal rail and saw the value even in face of large corporate resistance and hostility.   The team started small and grew as needed, bringing in and fostering the required skills.  A positive attitude that the goal was possible was shared by all.  Hard work and long hours were the norm for the group.  When the group’s proposal was approved but with the worst pilot project locations the group saw the opportunity to prove the concept and jumped right into it.  The core group shared leadership roles and had strong affinity of tacit information on specific skill sets.  They assumed a ask for forgiveness rather than permission attitude, and resolved impediments quickly.  The results was a change in the business model for the industry, intermodal rail is now common place and well established business process for the rail industry. 
Ch 3 Team Basics A Working Definition and Discipline
Teams are a “powerful vehicle for performance” (p. 43)  many companies are embracing teams as a unit of performance.  There are differences in understand of what a team is and what constitutes a performant team.   Teams work well when they have specific results to achieve, and the performance ethic of the organization demans those results.
“A team is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.” (p. 45)
Small number - in the Agile community we say 7 +/- 2  ( 5 - 9 members).  Reasoning is the tacit knowledge of each other (the group) and the intercommunication of the team.  The larger the number the lower the accountability for success.  Large numbers have logistical problems not seen in smaller groups (space to meet, etc.).  See Also: Choosing the Team Size in Scrum by Agile Pain Relief
Scrum (software development process) offers a way to scale teams to very large (hundreds) numbers.
Complementary skills - we call this a cross-functional team.  A team must have a person with the required skills to solve the problem, and it will take many skills to solve most any complex problem.   Many successful teams realize they lack certain skills, and become self reliant on learning or acquiring the skill set.
Committed to common purpose and performance goal.  Teams must see the purpose for their existence, be motivated to achieve the goal.  The best teams spend significant time discussing their purpose, reshaping it and refining that purpose over their lifetime.
Committed to a common approach.  Agreement on the approach, process to solve the problems is a key,  they may spend considerable time on this issue also. 
Mutual accountability.  Teams must hold each other accountable for the achievement of the goal, the quality of the products, and the process.  They must be capable of defining their own standards for performance and encouraged to raise the bar.  

Ch 5 The Team Performance Curve
A team does not start out at super high performance, it takes time to reach this goal.  Many teams never reach their potential.  Experts say that if a team does reach high-performance that it should not be disbanded but kept together, and given a new purpose.  The performance curve describes this growth to high-performance.
Work groups are not teams, though they may develop into a team.  One difference is the focus either on team performance or individual performance & accountabilities.
Pseudo-teams never agree on purpose, or accountability of the group, they get stuck in rituals and avoid rather than engage each other.

Ch 8  Teams, Obstacles and Endings:  Getting Unstuck
Every team will encounter obstacles, high-performing teams develop tools for overcoming these obstacles.  Teams lower of the performance curve may need help to over come obstacles of all natures.  Teams may become stuck, and not develop the tools to resolve their obstacles, then it is time for serious help.  Stuck teams: lack energy, or enthusiasm, have a sense of helplessness, lack identity, lack purpose, members are cynical, and have a high degree of mistrust.
A weak sense of direction - the team needs to create common goals, take joint responsibility.
Insufficient commitment to performance - team needs accountability for the problem and the solution, based in performance measures.
Critical skills gaps - team needs to hire experts or develop skills.  They must be capable of admitting they need help - identify the type of help and go get it.
Getting unstuck:  - 1) revisit the basic of teams, 2) build on small successes, 3) inject new information and techniques, 4) get facilitation skills & training, 5) change team membership or leader

Transitions and endings will also effect the team, may drop them back into lower stages of Tuckman model of development - allow for that, don’t expect no emotion for losses. 
Categories: Blogs

Mean Time between Disruptions (MTD) a leadership Metric

Agile Complexification Inverter - Sun, 02/19/2017 - 05:09
A rant on Metric's I wish I had written...  so I'm going to just include it by reference and call it my own.

One thousand Words on Metrics

Here's a quote to get you even more interested in clicking that link...
ConclusionIn short, I find most grasping for metrics to be a reliable metric for lack of understanding of human behavior, not only that of those who would be measured but that of those who would do the measuring.If a higher-up wants a metric about a team, say, as an input to their judgment about whether the team’s work is satisfactory, oughtn’t there be some other way to tell?And if I choose nearly any metric on someone else’s behalf, doesn’t that reveal my assumption that I know something about how they do their good work better than they do?Or worse, that I prefer they nail the metric than do something as loose and floppy as “good work”? Well - will you look at that!  Yareev's even willing to apply his own metric to his work.  What a great example of a leader...
Let’s try that againNew metric (expiration = next subhead, privacy = public): I’m 0 for 1 on satisfying conclusions to this post.I’m hardly an expert on human behavior. If I were one, rather than being passive-aggressive and obstructive, I’d have a ready step to suggest to metrics-wanters, one that they’d likely find more desirable than metrics.Instead I have to talk myself down from passo-aggro-obstructo, by which time they’ve chosen what they’ll observe and the ready step I can offer is limited to encouraging them to observe the effects of their observation.Can you give me some better ideas?Here's my very special response to his request for comments.

   I'm wanting to +1 your whole rant, I'd like to nail it to the front doors, I'm thinking about a tattoo, but unsure where on my leader's body it should go...

   I have sometimes fantasied about asking the VP that want's a new metric, if it would be good for us to add one that measured their leadership of our group - I'll call this metric Mean Time between Disruptions (MTD).  MTD is calculated much like the old factory sign that said:
 "its been 1023 days since we killed someone at this factory, please be safe."   So let's start counting (I suggest in weeks) the time between a major disruption to the team.  For this basic metric we are looking at team formation dynamics (your familiar with Tuckman's Forming, Storming, Norming, Performing) and you Mr. VP desire the P word - but it comes after 3 stages of development beyond the F word).

   Let's start at the beginning and count weeks between Forming and ReForming.  You know like when you move a person on/off a team.  When you move the team's physical location, or when you give the team a new objective, then let's reset the clock.

   The metrics I've seen range from MTD = 0 to about 20 weeks for many teams I've worked with.  And Mr. VP says they desire persistent teams.

I would have put it on his site in the comments but I got a very dissatisfied error message from the system when I posted it... (wonder if he has a metric for failed comments?).

Agile in 3 Minutes  a podcast that discusses a journey toward agility (each episode in exactly 3 minutes).  I'm pondering... why does the magic number 3 come up in the Agile community so often?  Personally I feel it has to do with the Book of Armaments, chapter 2, verse 9 to 21; because 5 is right out!



See Also:
Team Metrics - Case Study
How could we measure Team Happiness?
Metrics for a Scrum Team  but don't confuse that post with Scrum Team Metrics which discusses the necessary and sufficient metric Velocity.
Do you really need a Project Management Office? (PMO effectiveness metrics)


Categories: Blogs

Synergic Reading Lessons

Agile Complexification Inverter - Sun, 02/19/2017 - 05:04


Wondering what other books I should read concurrently with the philosophy of this book, Other Minds, on the mind of our alien ancestors. In chapter one Peter is already mashing up Ismael and Darwin, so I feel it appropriate to do a bit of mix-in myself. I'm thinking Seven Brief Lessons on Physics will add spice. To bad I recycled How to build a Mind at Half Price Books.




I've also got to read Coaching Agile Teams by Lyssa Adkins for work's book club. And I may mix-in a bit of LEGO Serious Play, because I cannot get serious about coaching - seems like a play activity to me.




Maybe I will devise a quadrant model of these books. A Venn diagram of their overlapping topics.



Squid Communicate With a Secret, Skin-Powered Alphabet
Categories: Blogs

TrumpCare in its Infancy January 2017

Agile Complexification Inverter - Sun, 02/19/2017 - 05:03
I'm extremely concerned today for my country and this planet.  It appears that history is repeating.
    January 27th -- International Holocaust Remembrance Day.

President Trump bars refugees and citizens of Muslim nations entry into the U.S.A.

The New York Times
By Bundesarchiv, Bild 183-N0827-318 / CC-BY-SA 3.0, CC BY-SA 3.0 de
Four score and four years ago a dictator brought forth on the European continent an evolving plan to rule the world and subjugate the masses.

Now we are engaged in a great resistance, testing whether our nation, or any nations conceived from the learning of our mothers and fathers and so dedicated to liberty, can long endure.  We are met on a great social square of technologic creation.  We have come to dedicate a portion of our wealth, wisdom, and life to those in history that have offered their lives and wisdom so that we may learn and prosper.  It is altogether fitting and proper that we should do this.

But, in a larger sense, we can not dedicate -- we can not consecrate -- we can not hallow -- this square.  The brave women and men, living and dead, who struggle here, have consecrated it, far above our poor power to add or detract.  The world will little note, nor long remember what we say here, but it can never forget what they did here in the commons.  It is for us the living, rather, to be dedicated here to the unfinished work which they who fought here have thus far so nobly advanced.  It is rather for us to be here dedicated to the great task remaining before us -- that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion -- that this nation, ruled by law, shall have a new birth of freedom -- and that government of the people, by the people, for the people, shall not perish from this planet.

-- David A. Koontz, human patriot


President Abraham Lincoln's address, on Thursday, November 19, 1863, to dedicate Soldiers' National Cemetery in Gettysburg, Pennsylvania, four and a half months after the Union armies defeated those of the Confederacy at the Battle of GettysburgFour score and seven years ago our fathers brought forth on this continent, a new nation, conceived in Liberty, and dedicated to the proposition that all men are created equal. Now we are engaged in a great civil war, testing whether that nation, or any nation so conceived and so dedicated, can long endure. We are met on a great battle-field of that war. We have come to dedicate a portion of that field, as a final resting place for those who here gave their lives that that nation might live. It is altogether fitting and proper that we should do this. But, in a larger sense, we can not dedicate—we can not consecrate—we can not hallow—this ground. The brave men, living and dead, who struggled here, have consecrated it, far above our poor power to add or detract. The world will little note, nor long remember what we say here, but it can never forget what they did here. It is for us the living, rather, to be dedicated here to the unfinished work which they who fought here have thus far so nobly advanced. It is rather for us to be here dedicated to the great task remaining before us—that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion—that we here highly resolve that these dead shall not have died in vain—that this nation, under God, shall have a new birth of freedom—and that government of the people, by the people, for the people, shall not perish from the earth.

"Abraham Lincoln's carefully crafted address, secondary to other presentations that day, was one of the greatest and most influential statements of national purpose. In just over two minutes, Lincoln reiterated the principles of human equality espoused by the Declaration of Independence[6] and proclaimed the Civil War as a struggle for the preservation of the Union sundered by the secession crisis,[7] with "a new birth of freedom"[8] that would bring true equality to all of its citizens.[9] Lincoln also redefined the Civil War as a struggle not just for the Union, but also for the principle of human equality.[6]".

"Lincoln's address followed the oration by Edward Everett, who subsequently included a copy of the Gettysburg Address in his 1864 book about the event (Address of the Hon. Edward Everett At the Consecration of the National Cemetery At Gettysburg, 19th November 1863, with the Dedicatory Speech of President Lincoln, and the Other Exercises of the Occasion; Accompanied by An Account of the Origin of the Undertaking and of the Arrangement of the Cemetery Grounds, and by a Map of the Battle-field and a Plan of the Cemetery)."
 -- Wikipedia, Gettysburg Address
The books title is indictavite of the author's ability to thoroughly cover a topic. Everett's 2-hour oration had 13,607 words.



See Also:
     The Address by Ken Burns - PBS. Did you hear the story about the person that would give $20 bucks to grandkids that learned the Gettysburg Address? Encouraged me to learn it and it's history. History has an interesting emergent property... it appears to repeat, this is a emergent property from a complex system. It is the complex system practicing and learning... Humans as part of this universe's system, are so far (as we know) it's fastest learning sub-system. Our apparent loop duration is currently around Four Score years.Why President Obama Didn't Say 'Under God' While Reading the Gettysburg Address
Lincoln's 272 Words, A Model Of Brevity For Modern Times by Scott Simon

    Germany's Enabling Act of 1933. "The Enabling Act gave Hitler plenary powers. It followed on the heels of the Reichstag Fire Decree, which abolished most civil liberties and transferred state powers to the Reich government. The combined effect of the two laws was to transform Hitler's government into a de facto legal dictatorship."
     Women's March 2017 "A series of worldwide protests on January 21, 2017, in support of women's rights and related causes. The rallies were aimed at Donald Trump, immediately following his inauguration as President of the United States, largely due to his statements and positions which had been deemed as anti-women or otherwise reprehensible."
     Reichstag Fire Decree - Germany 1933  According to Rudolf Diels, Hitler was heard shouting through the fire "these sub-humans do not understand how the people stand at our side. In their mouse-holes, out of which they now want to come, of course they hear nothing of the cheering of the masses."[1].   Seizing on the burning of the Reichstag building as the supposed opening salvo in a communist uprising, the Nazis were able to throw millions of Germans into a convulsion of fear at the threat of Communist terror. The official account stated:  The burning of the Reichstag was intended to be the signal for a bloody uprising and civil war. Large-scale pillaging in Berlin was planned for as early as four o’clock in the morning on Tuesday. It has been determined that starting today throughout Germany acts of terrorism were to begin against prominent individuals, against private property, against the lives and safety of the peaceful population, and general civil war was to be unleashed…[2]
     TrumpCare: In the Beginning by Bill Frist - Nov. 2016, Forbes.  "Yesterday Americans woke up to news of a new president-elect: Donald J. Trump. The immediate question for those whose lives focus around lifting the health of individual Americans is, “What does this mean for health care in America?”
Categories: Blogs

Refactoring Towards Resilience: Async Workflow Options

Jimmy Bogard - Fri, 02/17/2017 - 23:44

Other posts in this series:

In the last post, we looked at coupling options in our 3rd-party resources we use as part of "button-click" place order, and whether or not we truly needed that coupling or not. As a reminder, coupling is neither good nor bad, it's the side-effects of coupling to the business we need to evaluate in terms of desirable and undesirable, based on tradeoffs. We concluded that in terms of what we needed to couple:

  • Stripe: minimize checkout fallout rate; process offline
  • Sendgrid: Send offline
  • RabbitMQ: Send offline

Basically, none of our actions we determined to need to happen right at button click. This doesn't hold true for every checkout page, but we can make that assumption for this example.

Sidenote - in the real-life version of this, we opted for Stripe - undo, SendGrid - ignore, RabbitMQ - ignore, with offline manual re-sending based on alerts.

With this in mind, we can design a process that manages the side effects of an order placement separate from placing the order itself. This is going to make our process more complicated, but distributed system tend to be more complicated if we decide we don't want to blissfully ignore failures.

Starting the worfklow

Now that we've decided we can process our three resources out-of-band, the next question becomes "how do I signal to that back-end processing to do its work?" This largely depends on what your backend includes, if you're on-prem or cloud etc etc. Azure for example offers a number of options for us for "async processing" including:

  • Azure WebJobs
  • Azure Service Bus
  • Azure Scheduler

In my situation, we weren't deploying to Azure so that wasn't an option for us. For on-prem, we can look at:

From these three, I'm inclined towards Hangfire as it's easy to integrate into my Web API/MVC/ASP.NET Core app. A single background job executing say, once a minute, can check for any pending messages and send them along:

RecurringJob.AddOrUpdate(() => {  
    using (var db = new CartContext()) {
        var unsent = db.OutboxMessages.ToList();
        foreach (var msg in unsent) {
            Bus.Send(msg);
            db.OutboxMessages.Delete(msg);
        }
        db.SaveChanges();
    }
}, "*/1 * * * *");

Not too complicated, and this will catch any unsent messages from our API that we tried to send after the DB transaction. Once a minute should be quick enough to catch unsent messages and still not have it seem like to the end user that they're missing emails.

Now that we've got a way to kick off our workflow, let's look at our workflow options themselves.

Workflow options

There's still some ordering I need to enforce on my external resource operations, as I don't want emails to be sent without payment success. Additionally, because of the resilience options we saw earlier, I don't really want to couple each operation together. Because of this, I really want to break my workflow in multiple steps:

In our case, we can look at three major workflows: Routing Slip, Saga, and Process Manager. The Process Manager pattern can further break down into more detailed patterns, from the Microservices book "Choreography" and "Orchestration", or as I detailed them a few years back, "Controller" and "Observer".

With these options in mind, let's look at each in turn to see if they would be appropriate to use for our workflow.

Routing Slip

Routing slip is an interesting pattern that allows each individual step in the process to be decoupled from the overall process flow. With a routing slip, our process would look like:

We start create a message that includes a routing slip, and include a mechanism to forward along:

Bus.Route(msg, new [] {"Stripe", "SendGrid", "RabbitMQ"}  

Where "RabbitMQ" is really just and endpoint at this point to publish a "OrderComplete" message.

From the business perspective, does this flow make sense? Going back to our coordination options for Stripe, under what conditions should we flow to the next step? Always? Only on successful payment? How do we handle failures?

The downside of the Routing Slip pattern is it's quite difficult to introduce logic to our workflow, handle failures, retries etc. We've used it in the past successfully, and I even built an extension to NServiceBus for it, but it tends to fall down in our scenario especially around Stripe where I might need to do an refund. Additionally, it's not entirely clear if we publish our "Order Complete" message when SendGrid is down. Right now, it doesn't look good.

Saga

In the saga pattern, we have a series of actions and compensations, the canonical example being a travel booking. I'm booking together a flight, car, and hotel, and only if I can book all 3 do I call my travel booking "complete":

//vasters.com/archive/Sagas.html

Does a Saga make sense in my case? From our coordination examination, we found that only the Stripe resource had a capability of "Undo". I can't "Undo" a SendGrid call, nor can I "Undo" a message published.

For this reason, a Saga doesn't make much sense. Additionally, I don't really need to couple my process together like this. Sagas are great when I have an overall business transaction that I need to decompose into smaller, compensate-friendly transactions. That's clearly not what I have here.

Process Manager - Orchestration/Controller

Our third option is a process manager that acts as a controller, orchestrating a process/workflow from a central point:

Now, this still doesn't make much sense because we're coupling together several of our operations, making an assumption that our actions need to be coordinated in the first place.

So perhaps let's take a step back at our process, and examine what actually needs to be coordinated with what!

Process Examination

So far we've looked at process patterns and tried to bolt them onto our steps. Let's flip that, and go back to our original flow. We said our process had 4 main parts:

  1. Save order
  2. Process payment
  3. Email customer
  4. Notify downstream

From a coupling perspective, we said that "Process Payment" must happen only after I save the order. We also said that "Email customer" must happen only if "Process Payment" was successful. Additionally, our "notify downstream" step must only happen if our order successfully processed payment.

Taking a step back, isn't the "email customer" a form of notifying downstream systems that the order was created? Can we just make an additional consumer of the OrderCreatedEvent be one that sends onwards? I think so!

But we still have the issue of payment failure, so our process manager can handle those cases as well. And since we've already made payments asynchronous, we need some way to signal to the help team that an order is in a failed payment state.

With that in mind, our process will be a little of both, orchestration AND choreography:

We treat the email as just another subscriber of our event, and our process manager now is only really concerned about completing the order.

In our final post, we'll look at implementing our process manager using NServiceBus.

Categories: Blogs

New Case Study: Kantar Retail sees major gains in Delivery, Finance, and Human Resources with SAFe

Agile Product Owner - Fri, 02/17/2017 - 16:46

“Our time to market is impressive for an enterprise solution. It’s a competitive advantage in the market that we can make major product changes every two months.”

Cédric Guyot, CEO, Virtual Reality at Kantar Retail

case-study-box-kantarHow do you deliver faster, retain top talent, and carve out a competitive advantage—all while spending less? For Kantar Retail Virtual Reality (KRVR), our latest case study, the answer was in deploying SAFe.

Working with clients such as Walmart, Target, and Unilever, KRVR’s virtual reality solutions enable realistic consumer research using virtual stores. When the company set out to develop a new VR solution in 2013, team members at the small company worried that a more formal approach could stifle ideas, but SAFe provided the framework the company needed while preserving creativity.

KRVR began their SAFe implementation with just six team members, and has now grown to 30, including all aspects of software delivery, QA, Scrum Teams, and UI/UX. They didn’t leave it at that. Today, they also have SAFe fully implemented on the Team and Program levels.

Practicing SAFe, KRVR brought the latest version of its product to market. Cloud-based Kantar Retail VR Infinity™ puts VR technology directly in the hands of users, and connects teams and customers to understand issues and opportunities quickly. What’s really valuable in this story is that Kantar Retail took the time to measure results across three spectrums: Delivery, Finance, and Human Resources. Their story is one of the better examples that highlights the across-the-board effect that SAFe can have on an enterprise. As you can see here, practicing SAFe made a big difference for Kantar Retail:

Delivery
• Delivery of major releases down from 6 to 2 months
• Time to market decreased from 9 to 3 months
• Reduced time to respond to client feedback from 3 months to 1 month
• Greater predictability, which enhances client satisfaction

Finance
• 27.5% decrease in cost per epic

Human Resources
• 41% to 28% decrease in the attrition rate
• 36%-43% increase in team productivity due to clear job responsibilities and processes
• Easier talent acquisition and retention due to openness and transparency

Given those metrics, top management is fully behind SAFe. SAFe not only elevates internal team satisfaction and hiring; the sales team now brings the company’s time to market into conversations with prospects.

“We’ve adopted an enterprise framework for agility, the SAFe framework. We’ve been more consistent. We’ve been able to articulate a roadmap to the business and to our clients and deliver in time and in full, which is a really positive milestone..”

Eric Radermacher, Product Manager, Virtual Reality at Kantar Retail

Check out the company’s full case study here.

Many thanks to those who helped share KRVR’s SAFe story: Cedric Guyot, CEO; Dmytro Vavriv, PhD, Delivery Manager; Paul Gregory, CTO; Dmytro Tsybulskyi, Release Train Engineer; Eric Radermacher, Product Manager; and Timofey Yevgrashyn, SPC and Agile coach.

Stay SAFe!
—Dean

Categories: Blogs

How Agile Creates and Manages WIP Limits

Johanna Rothman - Thu, 02/16/2017 - 18:13

As I’m writing the agile project management book, I’m explaining how agile creates and manages WIP (Work in Progress) Limits.

Iteration-based agile manages WIP by estimating what you can do in an iteration. You might count points. Or, you use my preference, which is to count the (small) stories.

If you use flow-based approaches, you use kanban. You set WIP limits for the columns on your board.

In this image, there’s a limit of eight items in the Ready column, three in Dev and unit test, two in System test. The interesting question is how did this team decide on these limits?

This is a large-ish team. They have eight people aside from the PO: six developers and two testers. They decided to use a reasonable approximation for deciding on WIP limits:

  1. Take the number of people who work on a given column. That’s the numerator. Here, for the Dev and unit test column, it’s 6.
  2. Divide that number by 2. That gives you 3 as the WIP.

This team happens to have a policy of “No one works alone on the code,” so their approximation works well. You might have a product that requires a front-end, middleware, and back-end developer for each feature. You would have a WIP limit of 2 on the Dev and unit test column because you need three people for each feature.

Now, there are only two testers on this team. How did they get to a WIP limit of 2?

The testers do not work together. They each work independently. That means they can each work on a story. They can’t work on more than two stories at a time because they each take one story. This team agreed to work on stories until the story is done. There is no “Stuck” or “Waiting” column.

Every so often, the testers need help from the developers to complete a story. That’s because the developers didn’t realize something, or implemented something not quite right. In that case, the testers walk over to the developers and negotiate when the developer is available to help. Often, it’s right away. Yes, the developers stop what they are doing, because finishing something they thought was done is more important than starting or completing something new.

If you need a Stuck or Waiting column, you might add WIP limits to that column also. Why? Because you don’t want that column to turn into a purgatory/limbo column, where partly finished stories go and never emerge. You might call it Urgent, although I tend to reserve Urgent for support issues.

If you use iteration-based agile, and you have unfinished work at the end of the iteration, consider using a kanban board so you can see where the work in piling up. You might have a problem with “Everyone takes their own story.”  (See Board Tyranny in Iterations and Flow.)

If you have read Visualize Your Work So You Can Say No, consider adding WIP limits to your board. You might have noticed I say I don’t use WIP limits on my paper board because the paper, the size of my board, limits my work in progress.

Categories: Blogs

It’s Not All Business – My YouTube Gaming Channel

Derick Bailey - new ThoughtStream - Thu, 02/16/2017 - 14:30

Most of what I post these days, is very directly related to the “business” of software development – either code, concepts or just flat out business stuff with WatchMeCode and other related ventures.

But I’m not all business, all the time.

IMG 0401

In fact, I keep a rather high level of play time in my life and being self-employed just makes that easier as I can do pretty much what I want, when I’m at home during the week.

Not the least of which is playing video games.

Last November, it occurred to me that I could record and stream my game playing to YouTube directly from my PS4.

Shortly after, I realized I could download the videos from YouTube, edit them, add voice-over, and upload them again.

Then I found this great little game recording device: the Elgato HD60 S, and it was Christmas… sooo…

All said and done, I’ve been uploading videos to a dedicated YouTube gaming channel for a couple of months now. I’m not doing one-a-day like a lot of the big names are, but I’m trying to do at least one a week. And I’m having a ton of fun doing it!

If you’re interested in gaming, at all, and want to see what I’ve been playing lately, check out the channel.

Code-Ninja Gaming

I’ve been playing and recording a lot of Battlefield 1, but have recently been adding in Titanfall 2 and I just started For Honor. There’s plenty of other games that I play and want to record, as well. And I’ve recently started live-streaming again (now that I have a basic setup that is working with the HD60S).

It’s all just a matter of making time to record and edit… which can be difficult when I spend days and nights working on products, marketing and sales pages, and doing everything I can to be productive.

But having a hobby is important. And I’m having fun with this one!

The post It’s Not All Business – My YouTube Gaming Channel appeared first on DerickBailey.com.

Categories: Blogs

Boosting PMO's with Lean Thinking

Leading Answers - Mike Griffiths - Thu, 02/16/2017 - 03:11
Lean Thinking, described and popularized in the book “Lean Thinking” by James Womack and Daniel Jones, is summarized as: “focusing on delivering the most value from a customer perspective, while reducing waste and fully utilizing the skills and knowledge of... Mike Griffiths
Categories: Blogs

Sometimes Docker Is A Pain… Like The Failed Image Builds

Derick Bailey - new ThoughtStream - Wed, 02/15/2017 - 18:10

Working with Docker is generally a good experience for me. I’ve got enough of the tools down, I know most of the command line parameters that I need, and I can look up what I don’t have memorized yet.

But that doesn’t mean Docker is completely painless.

For example, I was recently recording a WatchMeCode episode and I wanted to suggest a simple way to help reduce the need to remember so many command-line options. Well, it didn’t go quite the way I wanted.

If something as “simple” as which command-line options are needed can be a huge source of problems, imagine how many issues can come up when editing a Dockerfile, configuring an image and generally trying to make your Docker image builds work.

The list is endless, and I’ve run into just about every single problem you can image.

  • missing “EXPOSE” instructions for TCP/IP ports
  • forgetting to “RUN” a “mkdir” to create the folder for the app
  • telling the Dockerfile to set the “USER” before you have the right folder permissions in place
  • leaving out critical environment variables, such as “NODE_ENV=production”
  • and more!

The problems are the bane of a developer’s life, in Docker. They are things we are not accustomed to dealing with. We write code, after all, not server configuration and deployment automation. But here we are, in this new world where we have become a critical part of the infrastructure and deployment process.

And while we truly are better off for this – we have a more consistent development and deployment experience, with far fewer (i.e. zero) “Works On My Machine” problems – we do have a few new frustrations to deal with.

Announcing the Debugging Docker Images webinar

Stop the endless cycles of debugging failed Docker image builds.

No more tweaking a Dockerfile – hoping to get it right – building, testing, watching it fail again, and then repeating the process… over, and over, and over, and over again.

Join me and the other 50+ developers that have registered, so far, for a live webinar on February 27th, 2017 at 20:00 UTC (2PM CST).

I’ll show you the tools and techniques that I use, to cut image build cycles down to a single “docker build” in most cases.

Debugging docker containers poster

Learn About the Webinar and Register to Attend ]

You’re guaranteed to see some techniques that will help you reduce the debugging cycles for your failed Docker image builds.

The post Sometimes Docker Is A Pain… Like The Failed Image Builds appeared first on DerickBailey.com.

Categories: Blogs

Scaling Scrum with Visual Studio Team Services

TV Agile - Wed, 02/15/2017 - 14:58
Watch and learn how to use Visual Studio Team Services to work with many teams on the same product. This presentation explains how to create a Nexus of 3-9 teams working on a single product with separate team backlogs and separate sprint backlogs while being able to visualise the total amount of work underway. Video […]
Categories: Blogs

Refactoring Towards Resilience: Evaluating Coupling

Jimmy Bogard - Tue, 02/14/2017 - 23:25

Other posts in this series:

So far, we've been looking at our options on how to coordinate various services, using Hohpe as our guide:

  • Ignore
  • Retry
  • Undo
  • Coordinate

These options, valid as they are, make an assumption that we need to coordinate our actions at a single point in time. One thing we haven't looked at is breaking the coupling of our actions, which greatly widens our ability to deal with failures. The types of coupling I encounter in distributed systems (but not limited to) include:

  • Behavioral
  • Temporal
  • Platform
  • Location
  • Process

In our code:

public async Task<ActionResult> ProcessPayment(CartModel model) {  
    var customer = await dbContext.Customers.FindAsync(model.CustomerId);
    var order = await CreateOrder(customer, model);
    var payment = await stripeService.PostPaymentAsync(order);
    await sendGridService.SendPaymentSuccessEmailAsync(order);
    await bus.Publish(new OrderCreatedEvent { Id = order.Id });
    return RedirectToAction("Success");
}

Of the coupling types we see here, the biggest offender is Temporal coupling. As part of placing the order for the customer's cart, we also tie together several other actions at the same time. But do we really need to? Let's look at the three external services we interact with and see if we really need to have these actions happen immediately.

Stripe Temporal Coupling

First up is our call to Stripe. This is a bit of a difficult decision - when the customer places their order, are we expected to process their payment immediately?

This is a tough question, and one that really needs to be answered by the business. When I worked on the cart/checkout team of a Fortune 50 company, we never charged the customer immediately. In fact, we did very little validation beyond basic required fields. Why? Because if anything failed validation, it increased the chance that the customer would abandon the checkout process (we called this the fallout rate). For our team, it made far more sense to process payments offline, and if anything went wrong, we'd just call the customer.

We don't necessarily have to have a black-and-white choice here, either. We could try the payment, and if it fails, mark the order as needing manual processing:

public async Task<ActionResult> ProcessPayment(CartModel model) {  
    var customer = await dbContext.Customers.FindAsync(model.CustomerId);
    var order = await CreateOrder(customer, model);
    try {
        var payment = await stripeService.PostPaymentAsync(order);
    } catch (Exception e) {
        Logger.Exception(e, $"Payment failed for order {order.Id}");
        order.MarkAsPaymentFailed();
    }
    if (!order.PaymentFailed) {
        await sendGridService.SendPaymentSuccessEmailAsync(order);
    }
    await bus.Publish(new OrderCreatedEvent { Id = order.Id });
    return RedirectToAction("Success");
}

There may also be business reasons why we can't process payment immediately. With orders that ship physical goods, we don't charge the customer until we've procured the product and it's ready to ship. Otherwise we might have to deal with refunds if we can't procure the product.

There are also valid business reasons why we'd want to process payments immediately, especially if what you're purchasing is digital (like a software license) or if what you're purchasing is a finite resource, like movie tickets. It's still not a hard and fast rule, we can always build business rules around the boundaries (treat them as reservations, and confirm when payment is complete).

Regardless of which direction we go, it's imperative we involve the business in our discussions. We don't have to make things technical, but each option involves a tradeoff that directly affects the business. For our purposes, let's assume we want to process payments offline, and just record the information (naturally doing whatever we need to secure data at rest).

SendGrid Temporal Coupling

Our question now is, when we place an order, do we need to send the confirmation email immediately? Or sometime later?

From the user's perspective, email is already an asynchronous messaging system, so there's already an expectation that the email won't arrive synchronously. We do expect the email to arrive "soon", but typically, there's some sort of delay. How much delay can we handle? That again depends on the transaction, but within a minute or two is my own personal expectation. I've had situations where we intentionally delay the email, as to not inundate the customer with emails.

We also need to consider what the email needs to be in response to. Does the email get sent as a result of successfully placing an order? Or posting the payment? If it's for posting the payment, we might be able to use Stripe Webhooks to send emails on successful payments. In our case, however, we really want to send the email on successful order placement not order payment.

Again, this is a business decision about exactly when our email goes out (and how many, for what trigger). The wording of the message depends on the condition, as we might have a message for "thank you for your order" and "there was a problem with your payment".

But regardless, we can decouple our email from our button click.

RabbitMQ Coupling

RabbitMQ is a bit of a more difficult question to answer. Typically, I generally assume that my broker is up. Just the fact that I'm using messaging here means that I'm temporally decoupled from recipients of the message. And since I'm using an event, I'm behaviorally decoupled from consumers.

However, not all is well and good in our world, because if my database transaction fails, I can't un-send my message. In an on-premise world with high availability, I might opt for 2PC and coordinate, but we've already seen that RabbitMQ doesn't support 2PC. And if I ever go to the cloud, there are all sorts of reasons why I wouldn't want to coordinate in the cloud.

If we can't coordinate, what then? It turns out there's already a well-established pattern for this - the outbox pattern.

In this pattern, instead of sending our messages immediately, we simply record our messages in the same database as our business data, in an "outbox" table":

public async Task<ActionResult> ProcessPayment(CartModel model) {  
    var customer = await dbContext.Customers.FindAsync(model.CustomerId);
    var order = await CreateOrder(customer, model);
    var payment = await stripeService.PostPaymentAsync(order);
    await sendGridService.SendPaymentSuccessEmailAsync(order);
    dbContext.SaveMessage(new OrderCreatedEvent { Id = order.Id });
    return RedirectToAction("Success");
}

Internally, we'll serialize our message into a simple outbox table:

public class Message {  
    public Guid Id { get; set; }
    public string Destination { get; set; }
    public byte[] Body { get; set; }
}

We'll serialize our message and store in our outbox, along with the destination. From there, we'll create some offline process that polls our table, sends our message, and deletes the original.

while (true) {  
    var unsentMessages = await dbContext.Messages.ToListAsync();
    var tasks = new List<Task>();
    foreach (var msg in unsentMessages) {
        tasks.Add(bus.SendAsync(msg)
           .ContinueWith(t => dbContext.Messages.Remove(msg)));
    }
    await Task.WhenAll(tasks.ToArray());
}

With an outbox in place, we'd still want to de-duplicate our messages, or at the very least, ensure our handlers are idempotent. And if we're using NServiceBus, we can quite simply turn on Outbox as a feature.

The outbox pattern lets us nearly mimic the 2PC coordination of messages and our database, and since this message is a critical one to send, warrants serious consideration of this approach.

With all these options considered, we're now able to design a solution that properly decouples our different distributed resources, still satisfying the business goals at hand. Our next post - workflow options!

Categories: Blogs

Invert Time Management; Schedule Energy

Agile Complexification Inverter - Tue, 02/14/2017 - 18:42
One can not manage Time. Why we talk like this is possible, might just lead to a billion dollar self help industry. Or we could invert the way we talk and think…

Scheduling Your Energy, Not Your Time By Scott AdamsYes that Scott Adams!
In that short article Scott give you his secret to success - it's basically free.  Now you could go out and buy a book like one of these to get other advice about your time usage.  Or - you could start by taking his (free) advice ... the decision is yours; but it's past time to make it.


The Time Of Your Life | RPM Life Management System $395 by Tony Robbins
100 Time Savers (2016 Edition) [obviously time sensitive information]Tell Your Time: How to Manage Your Schedule So You Can Live Free by Amy Lynn Andrews


See Also:
I'm Dysfunctional, You're Dysfunctional by Wendy Kaminer.    "The book is a strong critique of the self-help movement, and focuses criticism on other books on the subject matter, including topics of codependency and twelve-step programs. The author addresses the social implications of a society engaged in these types of solutions to their problems, and argues that they foster passivity, social isolation, and attitudes contrary to democracy."



Categories: Blogs

Docker Recipes eBook Update: Editor, New Content, and More

Derick Bailey - new ThoughtStream - Tue, 02/14/2017 - 14:30

It’s been a few weeks since the pre-sale of the Docker Recipes for Node.js Development ebook ended, and I haven’t spoken about it much but that doesn’t mean it’s been dormant!

Quite the opposite. In fact, I’m a bit overwhelmed by how quickly things are moving right now.

Buried by work

So I wanted to share an update on what’s been going on, what’s happening next, etc.

The Pre-Sale Numbers

A lot of people have been asking how the pre-sale went.

I had a goal of hitting 100 sales by the end of January, originally. That goal was smashed EASILY in the first week of the pre-sale, which prompted a bonus early recipe to be included in the book!

But the success of the book didn’t stop there.

All said and done, I saw a total of 265 sales of the ebook before the pre-sale period ended!

That number far exceeded my expectations for how well this pre-sale would do.

Thank you to everyone that bought into the pre-sale version! Your trust and willingness to support this book with your wallet is why I do this, and has given me what I need to ensure this book lives up to your standards.

Technical Editing

Probably most important thing to happen since the pre-sale ended – and as a direct result of how well the pre-sale went…  I’ve hired a technical editor!

This is something that I have wanted to do for every single eBook I’ve written, and I am extremely happy to have done so for this book.

I don’t want to call out any names yet (because I haven’t asked permissions, yet), but I can assure you that this editor has the chops that are needed for this book.

They are not only a great editor – having tackled some eBooks that I am more than familiar with, personally – they are also a Docker expert, eBook author and speaker!

I couldn’t have asked for a better match for an editor on this ebook, and I’m happy to say that they are already in the manuscript, tearing things apart and helping me put it back together.

The First Feedback Cycle

As a part of the ebook pre-sale, those that bought will be included in all feedback cycles for the ebook’s recipes.

The first round survey went out shortly after the pre-sale period ended, and I’ve received a TON of feedback already.

There are a wide variety of opinions, experience levels and ideas coming out of the feedback, including the general sentiment that the “Debugging with VS Code” recipe is a fan favorite, so far.

A number of people suggested the 2 debugging recipes may be better off as a single recipe, as well. This is something I had considered, and wasn’t sure of. But I’ll be leaning heavily on my editor to help me make that decision (and others).

I’m seeing a lot of questions and concerns around Windows based developers with Docker, for feedback and questions, too. This is a bit of a surprise for me, honestly, but it’s some of the most common feedback I’ve seen so far, and has me thinking about how I can best address that. There are are a few cases where I can add Windows specific recipes, and some other options for helping to alleviate the general concerns even before the recipes begin in the book.

New Recipes Coming Soon

With all of this feedback, and with some additional research that I’ve done on my own, I have a fair plan on the next 3 or 4 recipes (at least) to write for the book.

I’m hoping to have 1 more update to the book within February, but it may be early march, depending on scheduling for my editor and for myself.

Owners of the book will be getting updates sent out via email, as soon as they are available.

More Docker On The Way!

In the mean time, I’ve got more Docker content coming out – starting with the Debugging Docker Images webinar that I’ll be hosting on February 27th.

I’m expecting the Q&A session at the end of this to help drive some of the content for the book as well. Any and all questions, comments and feedback I get around Docker – from any source and any angle – will fuel the writing of this book.

The post Docker Recipes eBook Update: Editor, New Content, and More appeared first on DerickBailey.com.

Categories: Blogs

Article 5 in SAFe Implementation Roadmap series: Identify Value Streams and ARTs

Agile Product Owner - Tue, 02/14/2017 - 01:32
Click to enlarge.Click to enlarge.

Perhaps you’ve worked your way through the first five ‘critical moves’ in the SAFe Implementation Roadmap, and the big moment has arrived. You are now ready to actually implement SAFe. That means it’s time to Identify Value Streams and Agile Release Trains (ARTs), which is the topic of our latest guidance article in the Roadmap series.

If you think of value streams and ARTs as the organizational backbone of a SAFe transformation, you will understand their importance to this journey. Attempting to shortcut or breeze through this step would be the same as putting your foot on the brake at the same time you are trying to accelerate. But get this one right, and you’ll be well on your way to a successful transformation. This is a not-so-subtle hint to strongly encourage you to read this article, especially if you are engaging with SAFe for the first time.

This article covers the key activities involved in identifying value streams and ARTs. They include:

  • Identifying operational value streams
  • Identifying the systems that support the operational value stream
  • Identifying the people in the development value stream
  • Identifying ARTs

To assist you in this effort, the article provides two examples—one from healthcare, and one from financial services—that illustrate how specific elements of value flow to the customer.

Read the full article here.

As always, we welcome your thoughts so if you’d like to provide some feedback on this new series of articles, you’re invited to leave your comments here.

Stay SAFe!
—Dean and the Framework team

Categories: Blogs

We Need a Map

Agile Tools - Mon, 02/13/2017 - 05:57

map

“I have an existential map. It has ‘You are here’ written all over it.”

-Steven Wright

I happened to be in a cabin one evening after a long day of hunting. The wood stove was blazing and we were all chilling after dinner. The guides were off to one side hanging out together sharing their experiences from the day. It was fun to watch them as they described where they had been and what they had seen. The dialog would go something like this:

“We were down trail X off of the old logging road Y near the fork in the road and we didn’t see anything”
“You mean down past road Z near the bridge, right?”
“No, no, no. We were down logging road Y.”

Around and around they went.

At this point in the conversation they usually resort to hand gestures to further supplement the conversation. This goes on for a while and pretty soon it’s hard to tell whether you are looking at guides trying to tell each other where they were, or perhaps you are looking at a pair of fighter pilots describing their latest dogfight. There are hands waving wildly in the air. It’s Top Gun in the hunting cabin. Voices are raised, and expressions are animated.

And still they can’t seem to simply tell each other where they were. I’m watching all of this and I’m thinking, “These guys need a map.”

I’d laugh, but I see it all the time in software teams. If I’m honest, I catch myself doing it all the time. It seems that even with all the software that we have today, visualizing what we do and sharing it with each other is still a significant problem for us. How often do you find teams working together and trying to describe something – hands waving in the air and all. I guess we’re all future fighter pilots.

Like I said, I think sometimes what we really need is a map. I challenge you to go take a look at the walls in a second grade classroom. You’ll see nothing but maps. Maps of the US. Maps of the parts of a sentence. Maps of numbers. Everywhere there are maps of the knowledge that second graders consider important. What you see on those walls is the cartography of the eight year old mind.

Now go back to your office and look at the walls. What do you see? I’m betting that the walls are completely bare. Maybe you have some of those crappy motivational posters. If you are really lucky there is a map to the fire escape. There are no maps in the office of the typical knowledge worker. Why is that?

All too often we are like the guides in the cabin. We’re struggling to communicate simple concepts with each other – playing Top Gun. Maybe it’s time for a map.


Filed under: Agile, Teams Tagged: cartography, communication, knowledge work, maps, Software, Teams
Categories: Blogs

ReactJS/Material-UI: Cannot resolve module ‘material-ui/lib/’

Mark Needham - Mon, 02/13/2017 - 00:43

I’ve been playing around with ReactJS and the Material-UI library over the weekend and ran into this error while trying to follow one of the example from the demo application:

ERROR in ./src/app/modules/Foo.js
Module not found: Error: Cannot resolve module 'material-ui/lib/Subheader' in /Users/markneedham/neo/reactjs-test/src/app/modules
 @ ./src/app/modules/Foo.js 13:17-53
webpack: Failed to compile.

This was the component code:

import React from 'react'
import Subheader from 'material-ui/lib/Subheader'

export default React.createClass({
  render() {
    return 
    Some Text
    
  }
})

which is then rendered like this:

import Foo from './modules/Foo'
render(Foo, document.getElementById("app"))

I came across this post on Stack Overflow which seemed to describe a similar issue and led me to realise that I was actually on the wrong version of the documentation. I’m using version 0.16.7 but the demo I copied from is for version 0.15.0-alpha.1!

This is the component code that we actually want:

import React from 'react'
import Subheader from 'material-ui/Subheader'

export default React.createClass({
  render() {
    return 
    Some Text
    
  }
})

And that’s all I had to change. There are several other components that you’ll see the same error for and it looks like the change was made between the 0.14.x and 0.15.x series of the library.

The post ReactJS/Material-UI: Cannot resolve module ‘material-ui/lib/’ appeared first on Mark Needham.

Categories: Blogs

Refactoring Towards Resilience: Evaluating RabbitMQ Options

Jimmy Bogard - Fri, 02/10/2017 - 19:50

Other posts in this series:

In the last post, we looked at dealing with an API in SendGrid that basically only allows at-most-once calls. We can't undo anything, and we can't retry anything. We're going to find some similar issues with RabbitMQ (although it's not much different than other messaging systems).

RabbitMQ, like all queuing systems I can think of, offer a wide variety of reliability modes. In general, I try to make my message handlers idempotent, as it enables so many more options up stream. I also don't really trust anyone sending me messages so anything I can do to ensure MY system stays consistent despite what I might get sent is in my best interest.

Looking back at our original code:

public async Task<ActionResult> ProcessPayment(CartModel model) {  
    var customer = await dbContext.Customers.FindAsync(model.CustomerId);
    var order = await CreateOrder(customer, model);
    var payment = await stripeService.PostPaymentAsync(order);
    await sendGridService.SendPaymentSuccessEmailAsync(order);
    await bus.Publish(new OrderCreatedEvent { Id = order.Id });
    return RedirectToAction("Success");
}

We can see that if anything fails after the "bus.Publish" line, we don't really know what happened to our message. Did it get sent? Did it not? It's hard to tell, but going to our picture of our transaction model:

Transaction flow

And our options we have to consider as a reminder:

Coordination Options

Let's take a look at our options dealing with failures.

Ignore

Similar to our SendGrid solution, we could just ignore any failures with connecting to our broker:

public async Task<ActionResult> ProcessPayment(CartModel model) {  
    var customer = await dbContext.Customers.FindAsync(model.CustomerId);
    var order = await CreateOrder(customer, model);
    var payment = await stripeService.PostPaymentAsync(order);
    await sendGridService.SendPaymentSuccessEmailAsync(order);
    try {
        await bus.Publish(new OrderCreatedEvent { Id = order.Id });
    } catch (Exception e) {
        Logger.Exception(e, $"Failed to send order created event for order {order.Id}");
    }
    return RedirectToAction("Success");
}

This approach would shield us from connectivity failures with RabbitMQ, but we'd still need some sort of process to detect these failures and retry those sends later on. One way to do this would be simply to flag our orders:

} catch (Exception e) {
    order.NeedsOrderCreatedEventRaised = true;
    Logger.Exception(e, $"Failed to send order created event for order {order.Id}");
}    

It's not a very elegant solution, as I'd have to create flags for every single kind of message I send. Additionally, it ignores the issue of a database transaction rolling back, but my message is still sent. In that case, my message will still get sent, and consumers could get events for things that didn't actually happen! There are other ways to fix this - but for now, let's cover our other options.

Retry

Retries are interesting in RabbitMQ because although it's fairly easy to retry my message on my side, there's no guarantee that consumers can support a message if it came in twice. However, in my applications, I try as much as possible to make my message consumers idempotent. It makes life so much easier, and allows so many more options, if I can retry my message.

Since my original message includes the unique order ID, a natural correlation identifier, consumers can have an easy way of ensuring their operations are idempotent as well.

The mechanics of a retry could be similar to our above example - mark the order as needing a retry of the event to be raised at some later point in time, or retry in the same block, or include a resiliency layer on top of sending.

Undo

RabbitMQ doesn't support any sort of "undo" natively, so if we wanted to do this ourselves, we'd have to have some sort of compensating event published. Perhaps an event, "OrderNotActuallyCreatedJustKiddingAboutBefore"?

Perhaps not.

Coordinate

RabbitMQ does not natively support any sort of two-phase commit, so coordination is out.

Next steps

Now that we've examined all of our options around the various services our application integrates with, I want to evaluate each service in terms of the coupling we have today, and determine if we truly need that level of coupling.

Categories: Blogs

Why I Use a Paper Kanban Board

Johanna Rothman - Fri, 02/10/2017 - 17:37

My most recent post about how to Visualize Your Work So You Can Say No showing a couple of different kanbans was quite popular. Several people ask me how I use my personal kanban.

I use paper. Here’s why I don’t use a tool:

  • I am too likely to put too much into a tool. I put all this week’s work, next week’s work, next month’s and next year’s work, even though I’m not going to think about anything that far out. Paper helps me contain my To Do list.
  • When I collaborate with others, they want to break down the stories (large as they may be) into tasks. No!! I can’t take tasks. I need to see the value. See my post about From Tasks to Stories with Value.
  • I change my board, depending on what’s going on. I often have a week-based kanban because I retrospect at the end of the week. I often—not always—have a “today” column.

This is what my board looks like this week. it might look like this for a while because I’m trying to finish a book. (I have several more books planned, so yes, I will have a bunch of work “in progress” for the next several months/rest of the year.)

I have several chapters in This Week. I have two chapters in “Today:” That helps me focus on the work I want to finish this week and today. As a technical editor for agileconnection.com and as a shepherd for XP 2017, I have work in “Waiting to Discuss.” I will discuss other people’s writing.

Earlier this week, I had interactions with a potential client, so that work is now in Waiting for Feedback. Sometimes, I have book chapters there, if I need to discuss what the heck goes in there and doesn’t go in a chapter.

I haven’t finished much yet this week. I am quite close on two chapters, which I expect to finish today. My acceptance criteria is ready for my editor to read. I do not expect them to be done as in publishable. I’ll do that after I receive editorial feedback.

Could I do this on an electronic board? Of course.

However, I limit my WIP by staying with paper. I can’t add any more to the paper.

Should I have WIP limits? Maybe. If I worked on a project, I would definitely have WIP limits. However, the fact that I use paper limits what I can add to my board. If I notice I have work building up in any of the Waiting columns, I can ask myself: What can I do to move those puppies to Done before I take something off the Today or To Do columns?

I’ve been using personal kanban inside one-week iterations since I read Benson’s and Barry’s book, Personal Kanban. (See my book review, Book Review: Personal Kanban: Mapping Work | Navigating Life.

I recommend it for a job search. (See Manage Your Job Search and  Personal Kanban for Your Job Hunt.

You should use whatever you want as a tool. Me, I’m sticking with paper for now. I don’t measure my cycle time or lead time, which are good reasons to use an electronic board. I also don’t measure my cumulative flow, which is another reason to use a board.

I do recommend that until you know what your flow is, you use paper. And, if you realize you need to change your flow, return to paper until you really understand your flow. You don’t need a gazillion columns, which is easy to do in a tool. Use the fewest number of columns that help you achieve control over your work nad provide you the information you need.

Question for you: Do you want to see a parking lot board? I have images of these in Manage Your Project Portfolio, but you might want to see my parking lot board. Let me know.

Categories: Blogs