Skip to content

Feed aggregator

Refactoring Towards Resilience: Evaluating SendGrid Options

Jimmy Bogard - Thu, 02/02/2017 - 17:26

Other posts in this series:

In the last post, we found we had the full gamut of options for coordinating our distributed activity:

Coordination Options

We could ignore the failure (and have money floating in the ether), retry using an idempotency key, undo via a refund, or coordinate using the auth/capture flow Stripe provides. That's quite helpful that we have so many options available, it lets us be flexible in our approach. Part of this is the design of the Stripe API, and part is just the nature of payments.

SendGrid, a service to send email, naturally won't have as many options. The purpose of SendGrid is to send emails when you call their API, and to send that email as quickly as possible. You shouldn't call their API unless you want an email sent. With this in mind, let's look at our coordination options.

Ignore

With Stripe, the Ignore option wasn't really viable. We need to charge customers, but we don't want to charge them twice. With an email notification, it's not necessarily as critical.

In our original code, any SendGrid failure caused my entire process to fail:

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");
}

But what if it doesn't have to be this way? Does a SendGrid failure really need to take my entire payment process down? Should I not take people's money because I can't send them an email? Maybe not! The simplest approach would be just to ignore (and log) failures:

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);
    try {
        await sendGridService.SendPaymentSuccessEmailAsync(order);
    } catch (Exception e) {
        Logger.Exception(e, $"Failed to send payment email for order {order.Id}");
    }
    await bus.Publish(new OrderCreatedEvent { Id = order.Id });
    return RedirectToAction("Success");
}

We'd still want to send emails, but we can be notified of these exceptions and have some manual (or automated) process to retry emails.

Retry

Unlike Stripe, SendGrid does not support any sort of idempotency in requests. This is intentional on their part, they want to send emails as soon as possible and introducing any sort of idempotency check would introduce a delay in the send.

All this means that Retrying a SendGrid call would result in two emails sent. Is this acceptable? Probably not - if I received two "payment successful" emails, I would rightly freak out and assume my card was charged twice.

Fundamentally, my emails are SMTP, another messaging protocol, which just doesn't support something like idempotent Retry. If I wanted true retries, I would need to build a resiliency layer on top of sending emails, something that SendGrid (and most email service providers I can think of) do not do.

No retries.

Undo

Similar to Undo, there's really no such thing as "undoing" an email sent. Perhaps a follow-up email "ignore that last email", but that's about it.

SendGrid does however support scheduling emails in a batch with an ID, and cancelling a batch. However, there are limitations to batches sent, and batches are as the name implies a means to send a bunch of emails at a time in a batch.

I don't really want to be tied to scheduling a batch of emails together, as the customer expectation is to get an email relatively soon after send, and I can't create a batch for every single email.

No undos.

Coordinate

Similar to Retry, there's really no facility to coordinate an email send with some sort of two-phase commit process. I'd have to build something on top of calling the SendGrid API to coordinate this action.

No coordination.

So where does that leave us? In our current state, we can either Retry or Ignore. Neither are great solutions, but we'll come back soon on better ways to tackle this problem with messaging.

Next up, RabbitMQ failures!

Categories: Blogs

Let America Be America Again

With this month being Black History Month as well as today being Langston Hughes’ birthday I thought it’d be appropriate to share one of…

Categories: Blogs

ACE! Conference on Lean and Agile Software Development, Krakow, Poland, May 11-12 2017

Scrum Expert - Thu, 02/02/2017 - 10:00
The ACE! Conference on Lean and Agile Software Development is a two-day conference that brings together in Krakow (Poland) some of the best-known Agile, Scrum and lean practitioners in Europe and abroad. It is the guaranty of a great networking experience for agile software development practitioners that will come away with new ideas and enthusiasm. In the agenda of the ACE! Conference on Lean and Agile Software Development you can find topics like “Antipatterns for Diversity”, “The systemic Scrum Master”, “UX is team work”, “From Lean Startup to an Innovation Organization”, “How to facilitate a product backlog refinement session”, “Corporate environment, agile design and user experience”, “Execute a non-reactionary UX strategy”, “Selfish Accessibility”, “Remote User Testing”, “Designing to Learn: Creating Effective MVPs”, “Growing Your Discovery Mindset”, “Agile Architecture from the Trenches”, “Managing Stars”, “Your code smells too! Time to deodorize”, “Problem-solving techniques for groups”, “Being Agile to become Customer centric”. Web site: http://aceconf.com/ Location for the ACE! Conference on Lean and Agile Software Development: Efekt Express Hotel, ul. Opolska 14 31-323 Kraków
Categories: Communities

How to create your own Lint rule

Xebia Blog - Thu, 02/02/2017 - 09:12
When you are part of a multi-team project in Android, it becomes relatively hard to have a common understanding of how components should be used. This is where Android Lint can help you! In this blog we will show you how you can write your own Lint rules and test them. As an example, we
Categories: Companies

Q: What is an Agile Transition Guide?

Agile Complexification Inverter - Wed, 02/01/2017 - 23:39
David Koontz guiding a canoeI was at the Dallas Tech Fest last week and was asked several times what an Agile Transition Guide was (it was a title on my name tag)... it's surprising to me how many people assume they know what an Agile Coach is, yet there is no good definition or professional organization (with a possible exception coming: Agile Coaching Institute).

So naturally the conversation went something like this:

Inquisitive person:  "Hi David, what's an Agile Transition Guide?  Is that like a coach?"

David:  "Hi, glad you asked.  What does a coach do in your experience?"

Inquisitive person: "They help people and teams improve their software practices."

David:  "Yes, I do that also."

Inquisitive person: "Oh, well then why don't you call yourself a coach?"

David:  "Great question:  Let's see...  well one of the foundational principles of coaching (ICF) is that the coached asks for and desires an interaction with the coach, there is no authority assigning the relationship, or the tasks of coaching.  So do you see why I don't call myself a coach?"

Inquisitive person: "Well no, not really.  That's just semantics.  So you're not a coach... OK, but what's is a guide?"

David:  "Have you ever been fishing with a guide, or been whitewater rafting with a guide, or been on a tour with a guide?  What do they do differently than a coach?  Did you get to choose your guide, or were they assigned to your group?"

Inquisitive person: "Oh, yeah.  I've been trout fishing with a guide, they were very helpful, we caught a lot of fish, and had more fun than going on our own.  They also had some great gear and lots of local knowledge of where to find the trout."

David:  "Well, there you have it... that's a guide - an expert, a person that has years of experience, has techniques to share and increase your JOY with a new experience."

Inquisitive person: "Yes, I'm starting to see that difference, but can't a coach do this also?"

David:  "No, not unless the coach is willing to switch to a different modality - to one of mentoring, teaching, consulting, or protecting.  Some times a guide must take over for the participant and keep the person/group within the bounds of safety - think about a whitewater river guide.  A coach - by strict interpretation of the ethics, is not allowed to protect the person from their own decisions (even if there are foreseen consequence of this action."

Richard FeynmanAnd now the conversation start to get very interesting, the Whys start to flow and we can go down the various paths to understanding.  See Richard Feynman's dialogue about "Why questions"

So, I'm not a Coach

I've been hired as a coach (largely because the organization didn't truly understand the label, role, and the ethics of coaching).  This relationship was typically dysfunctional from the standpoint of being a coach.  So I decide to study the role of coaching. I've done a few classes, seminars, personal one of one coach, read a lot and drawn some conclusions from my study - I'm not good a coaching within the environment and situation that Agile Coaches are hired. I've learned that regardless of the title that an organization uses (Agile Coach, Scrum Master, etc.) it doesn't mean coaching.  It intends the relationship to be vastly different.  Since I'm very techie, I appreciate using the correct words, and phrase for a concept.  (Paraphrasing Phil Karlton: In software there are two major challenges: cache invalidation and naming things.  Two Hard Things)

So to stop the confusing and the absurd use of the terms, I quit referring to my role and skills as coaching.  Then I needed a new term.  And having lots of friends that have been Outward Bound instructors and understanding their roles, the concept of a river guide appeals to me in this Agile transformational role.  Therefore I coin the term Agile Transformation Guide.  But many organization do not wish to transform their organization, but they do wish for some type of transition, perhaps from tradition development to a more agile or lean mindset.  So a transition guide is more generic, capable of the situational awareness of the desire of the organization.




What does a guide really do?  
This question may best be answered by David Kelley in his TED talk, "How to build your creative confidence."  In this talk David points out his desire to teach parents that there are not two types of children - the creative and the non-creative.  There are, however, children that lost their desire to express their unique talents early in their lives.  He helps people regain this capability.

It is much like how Dr Bandura has developed his treatment for phobias.  David will tell you about this basic guided mastery technique that restores self efficacy.

How to build your creative confidence. TED Talk by David Kelley
This is what an Agile Transition Guide does... they guide you on a journey toward self efficacy via many techniques in mastery of your domain skills and capabilities.

See Also:
Six Kinds of Agile Coaches by Ravi Verma Describes the HUGeB coach, the one to be.
So what is a Coach and What is a Trainer - Agile 102
Where Agile goes to Die - Dave Nicolette - about those companies that are late adopters or laggards in the innovation curve and the challenges that "coaches" have when engaging with them.
The Difference Between Coaching & Mentoring

Scrum Master vs Scrum Coach by Charles Bradley

Agile Coach -or- Transition Guide to Agility by David Koontz; the whitewater guide analogy to agile coaching.

Academic paper:  Coaching in an Agile Context by David Koontz

What is the ROI of Agile Coaching - Payton Consulting

Interesting Twitter conversation about the nature of "coaching" with Agile42 group.



Categories: Blogs

Refactoring Towards Resilience: Evaluating Stripe Options

Jimmy Bogard - Wed, 02/01/2017 - 22:44

Other posts in this series:

In the last post, I looked at a common problem in web applications - accepting payments via 3rd party APIs (in this case, Stripe). We saw a fundamental issue in our design - because Stripe does not participate in our transactions, any failures after a call to Stripe will result in money being lost in the ether. For reference, 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");
}

How can we address this "missing money" problem? With each interaction, we have four basic options:

Coordination Options

We need to look at each of our Stripe interactions and based on which of these options are available, decide what coordination action we need to take. Above all though, we need to make sure the end user's expectations are still met. It's all for naught if we implement a back-end process that isn't explicitly communicated to the user.

Up until this point, our code picked option #1, "Ignore" for any failures. If a later failure occurred, we ignored the result and our action remained "successful". We can do better of course, and Stripe have a number of options available to use. Let's look at these options one at a time.

Retry

First, what about "Retry"? We could retry our Stripe payment, but that would result in two payments issues to the customer! Not exactly what we want. It turns out, however, that Stripe can handle idempotent requests by passing in some sort of client-generated idempotency key. From the docs, idempotency keys passed to Stripe expire within 24 hours. This means we can safely retry as many times as we want within 24 hours.

For our idempotency key, we can look at something unique in the cart, perhaps the Cart's ID? In this case, our code would look slightly different in our payments:

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, model.CartId);
    await sendGridService.SendPaymentSuccessEmailAsync(order);
    await bus.Publish(new OrderCreatedEvent { Id = order.Id });
    return RedirectToAction("Success");
}

With this in place, we can retry our action and our payment will be posted only once. But wait - who is retrying? What's the mechanism for our payment to be retried? We have a couple of options here. First, we can bake in some sort of "retry" in our Stripe service. Try X number of times, and finally fail and throw an exception if the payment didn't work.

That won't help in the case of a subsequent step failure, with SendGrid or RabbitMQ, however. If we wanted to retry the entire action, we'd likely need something on the client side to detect failures and retry the POST as necessary. In reality, we'd want to have more control over this retry process than driving it from the browser.

Undo

Undo is interesting in that it allows to perform a compensating action in case of subsequent failures. The "undo" action is highly dependent on what our action is in the first place. In the case of a Stripe payment, what would an "undo" action be? Like all payment gateways I'm aware of, Stripe allows the ability to refund any transaction. We only need to refund the customer if anything goes wrong:

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

This doesn't quite address the problem, though, as something could still go wrong with our transaction. We really need to handle the database transaction explicitly ourselves. We'd want to extend our solution just a bit, devising a way to tell our MVC transaction filter to not open a transaction if we're explicitly opening one in our action:

[ExplicitTransaction]
public async Task<ActionResult> ProcessPayment(CartModel model) {  
    StripePayment payment = null;
    try {
        dbContext.BeginTransaction();
        var customer = await dbContext.Customers.FindAsync(model.CustomerId);
        var order = await CreateOrder(customer, model);
        payment = await stripeService.PostPaymentAsync(order);
        await sendGridService.SendPaymentSuccessEmailAsync(order);
        await bus.Publish(new OrderCreatedEvent { Id = order.Id });
        await dbContext.CommitTransactionAsync();
    } catch {
        if (payment != null) {
            await stripeService.RefundPaymentAsync(payment);
        }
        await dbContext.RollbackTransactionAsync();
        throw;
    }
    return RedirectToAction("Success");
}

Now we've got explicit control over our database transaction, and in the case of failure, we undo any Stripe transaction with a refund, and rollback our database transaction. All is tidied up! Well, unless the refund fails, but that's a different problem.

Coordinate

Stripe cannot participate in a two-phase commit - or can it? A two-phase commit with a payment gateway would look something like:

  1. Authorize the card for a charge
  2. Charge the card

It turns out that credit cards to support this sort of approach, it just can look weird in your account. You might see "pending transactions", and in fact, you're probably already used to seeing this. Many hotels and rental companies authorize a charge on your card, then either charge the card for incidentals or just let the authorization expire.

Stripe has this option as well, with the auth-capture flow. Un-captured authorizations will be reversed after 7 days, and on top of that, we can go into the Stripe admin site to see any un-captured authorizations to capture them as necessary. We can't really do two-phase commit inside our web flow (since we don't have an actual coordinator), but we can come close. In this new flow, we'd authorize after everything else succeeded:

[ExplicitTransaction]
public async Task<ActionResult> ProcessPayment(CartModel model) {  
    StripePayment payment = null;
    try {
        dbContext.BeginTransaction();
        var customer = await dbContext.Customers.FindAsync(model.CustomerId);
        var order = await CreateOrder(customer, model);
        payment = await stripeService.PostAuthorizationAsync(order);
        await sendGridService.SendPaymentSuccessEmailAsync(order);
        await bus.Publish(new OrderCreatedEvent { Id = order.Id });
        await dbContext.CommitTransactionAsync();
    } catch {
        await dbContext.RollbackTransactionAsync();
        throw;
    }
    try {
        await stripeService.PostPaymentCaptureAsync(payment);
    } catch {
        Logger.Warning("Stripe authorization failed; authorize manually via Stripe UI");
    }
    return RedirectToAction("Success");
}

Once everything's succeeded on our side, we can finalize the authorization against Stripe. If anything goes wrong with our "PostAuthorizationAsync" call, we'll just swallow the error since we can always go into the Stripe UI and authorize ourselves.

In actuality, none of these options are that great, but if I want to preserve the behavior from the client of "card will be charged at button click". In most e-commerce apps I've been involved with, we tend not to charge right at button click since failures are difficult to recover from.

In the next post, we'll look at our options with SendGrid.

Categories: Blogs

A Very Short Course in Function Point Analysis

Agile Estimator - Wed, 02/01/2017 - 21:47

Metaphor for Function Points

When I was going to college and even when I first graduated, I used to work with my father doing roofing. One day he told me to flash the skylight on a roof we were working on. (If you don’t know what this means, don’t worry about it.) My father joking said, “I’ve been a roofer for 30 years as man and boy, and you expect me to just tell you about roofing?” I shrugged. He continued, “Don’t worry. If you have 15 minutes I will explain everything you need to know.” That is the spirit of this post. I do not want to slight either roofers or function point counters. if you are a function point counter or even an estimator who works with function points, you probably do not need to read this post at all. However, if you are an analyst, product manager, agile developer, this post should teach you what you need to know about function points in order to proceed with agile estimating.

Originally, function points were developed for estimating software development. IBM was developing systems in COBOL and PL/I. The same system might require a different number of lines of code depending on the programming language. Therefore, they wanted a measure that would be the same regardless of programming language. They developed function points. The function points measured both functional and non-functional requirements. In order to achieve vendor independence, the responsibility for function points was transferred to the International Function Point Users Group (IFPUG). Other versions of function points have come and gone. Some are still in use today. But the IFPUG version is the most commonly used. It is the variant being described here. The key to sizing in function points is to transform the application to be counted into the metaphor pictured above. It probably involves a couple of hundred rules, but only the most commonly used ones will be discussed below.

Boundary and scope are a concern when function point counting. What if an application is multi-tiered, i.e. what if some of it is implemented on a mainframe and some on a phone? Are they separate applications? Counters would say no, there is one boundary. Estimators should say the same thing, even if the work is being performed by two separate teams. Breaking up the development would ignore the communications overhead between the two teams. It would understate the effort and schedule of the total project. Are there times when counters and estimators might disagree regarding the boundary. Yes, conversion work is often such a case. For example, suppose a new version of a legacy system is being developed. As part of this effort, the existing data must be converted and loaded into the new application. Function point counters would say that each logical file that receives a load of converted data would be an external input into the new application. The conversion is a one-time job, so it is part of the project, but it does not become part of the application. Estimators often break the conversion work into a separate project with a separate boundary. It may end up with a good deal of data cleaning and other activities not considered in the function point counting scenario. An estimator should use the function point counters approach unless doing otherwise would deliver a better estimate.

The key to transforming the application to be sized into the metaphor above is to take all of the parts of the application and distribute them into the data (Internal Logical Files and External Interface Files) and transactions (External Inputs, External Outputs and External Inquiries) shown above. This can be done with externals like screens and reports or with user stories early in the life cycle. In any case, there is a many-to-many relationship between the application components and the functional components. For example, suppose there was a user story that stated, “As a trader, I want to maintain a list of futures contracts that I am following.” This statement means that there is an Internal Logical File (ILF) called Futures. There should be three External Inputs (EIs), one each to add, change and delete information about a futures contract. There would also be an External Inquiry (EQ) to show what the input looked like before the change input. However, if there was a user story stating, “As a trader, I will get an error message if erroneous information is entered.” no new transaction is identified. It is part of the add, change and delete inputs that we already counted. All of the function point components can have 3 levels of complexity: low, average and high. The complexity is a function of the amount of data involved in the transaction. Each level of complexity has a different function point weight. It is often impossible to know how much data is involved in a transaction early in the life cycle. It is unnecessary to know how to calculate the number of function points at this time.

There are two types of data, or logical files, in the function point metaphor: ILFs and External Interface Files (EIFs). Looking at the metaphor at the top of the page tells most of the story. An ILF is a store of date in the application to be sized. The EIF is an ILF in some other application that the application to be sized accesses in a read-only fashion. Every EIF is someone else’s ILF. Some ILFs are some else’s EIF. So now, what is an ILF? They are often the main physical files in an application. They are user identifiable. Early in the life cycle, they are the nouns that are in user stories. In the user story shown in the previous paragraph, Futures Contracts would probably be an ILF. The complexity of the data is a function of the number of  data items and Record Element Types (RETs) that are in the logical file. RETs usually correspond to the other logical files that are related to a particular file. All of this is frequently unknowable early in the life cycle.

Transactions are External Inputs (EIs), External Outputs (EOs) and External Inquiries (EQs). They have a quite a few attributes in common. For one thing, they all cross the application boundary. If there is a batch process that reads from one ILF and updates another, then this is not a functional transaction. It is not counted using function points. They are all elementary processes. Information engineering defined an elementary process as the smallest process that was of interest to the business. Elementary processes are best explained with examples that will be given below when each of the transaction types are elaborated on. Finally, they are unique. If the same report is sent to a trader and another account owner, it is one EO, not two. The bad news is that elementary processes and uniqueness can sometimes be complicated topics for function point counters; the good news is that most of the cases will fall into a reasonably small set of patterns that an estimator can determine. The complexity of a transaction is determined by the number of data items involved as well as the number of File Types Referenced (FTRs). FTRs is simply the number of ILFs and EIFs that the transaction interacts with. You guessed it; this information is frequently unknowable early in the life cycle.

External Inputs (EIs) originate from outside of the application and cross the boundary. Usually, they write to one or more ILFs. The classic example is a transaction file that is processed by the application. It often is more than one transaction type in the file. For example, there might be a transaction to add a new entry into an ILF, another one to change the data in an existing entry in the ILF and one to delete entries. In this example, there is one physical transaction file, but three different EIs. Everything that was just said about transaction files also applies to screens. A maintenance screen will often have separate EIs for add, change and delete functions. Function points are also applicable to real time. A typical EI might be input from a thermostat or a bar code reader. EIs mostly deal with data. For example, some applications have menu screens that require the user to choose which screen to proceed to next. These are NOT EIs. They are not considered functionality at all.

Checking the metaphor shows that there are two way that data can leave the boundary of the application being counted: External Outputs (EOs) and External Inquiries (EQs). Why two? The EOs tend to be a little more complicated, and thus have more function point weight associated with them. We have not explained how to calculate the function points. This is explained in many places as well as being built into any tool that maintains function point counts. It is not that important to learn. In what ways are EOs more complicated. One possibility is that calculations are performed. Any report that has totals or calculates derived detail values is an EO, not an EQ. The other common complication is that an EO might update an ILF. For example, if there is a program that generates checks, and updates a file so that an interruption in check processing does not lead to duplicate checks being printed, then it is an EO, not an EQ. An EO may contain an input if it is part of the same elementary process. For example, if a screen accepts a social security number and displays pay check information along with year-to-date totals, then it is an EO, not an EI and an EO.

Historically, EQs were intended to be simple outputs from an application. For example, if there was a screen that accepted a social security number, read pay check information from an ILF and then displayed it without doing any calculations, then this was an EQ. This is still the case. However, now an EQ is anything that presents information from an ILF without updating an ILF or performing calculations. Screen drop downs that read from ILFs are EQs, but only counted once per application, not once per screen where they are used. A report that does not require any calculations or update any ILFs is an EQ, not an EO. Emails or messages that exit an application may be EOs or EQs, depending upon whether they present calculations or update ILFs. However, if they are error messages, they are neither. Error messages are considered to be part of the EI that raised the error. There is a fundamental difference between EIs and EOs/EQs. If I have an input file with adds, changes and deletes, then there will be 3 EIs. However, if I generate a transaction file in my application with adds, changes and deletes, it is a single EO or EQ.

For completeness, we have to cover the Value Adjustment Factor. When function points were invented, it was understood that you needed to consider non-functional requirements in order to estimate. Everything above had to do with what the application was intended to do. How it would do in it was the technical or non-functional considers. 14 general systems characteristics were identified. These considered topics like backup and recovery, various forms of complexity including logical and mathematical, features to facilitate end user efficiency and more. However, the industry has decided that they did not cover enough. Estimating tools like COCOMO II use function points without the VAF, along with their own cost drivers to take the place of the VAF. IFPUG had created a Software Non-functional Assessment Process (SNAP) to take the place of the VAF. A few people have argued that calculating the VAF is a way to compare new projects to historical ones that were counted using it. For agile estimators, the VAF is best forgotten!

Categories: Blogs

How to lose customers via failure of your core business proposition

Agile Complexification Inverter - Wed, 02/01/2017 - 18:23
MayhemJust last month I receive a congratulatory letter from REI MasterCard - 10 years of a mutually beneficial business relationship ....  until .... chaos ensued (thank you Mr. Mayhem).  So I accepted the opportunity to communicate with my business lender on an incident that made me very dissatisfied with their policies.


Subject: Re: Congratulations on your REI World MasterCard anniversary! Thank you Robert,
     Just to let you know - I’m sure this will interest you - I will shortly be canceling my 10 year relationship with REI MasterCard, because of the quality of service you have just required me to deal with. I’ve got a great payment history and have been using our card to pay bills on line and automagically for years. Recently through my oversight, I forgot to pay my bill on time. So in response to this great customer who always pays his bills and once in 10 years paid late, your organization saw fit to block all payments, causing further confusion and customer / client dissections with your service level. When I called in to rectify the situation your senior rep. could not do anything to help - your policy prevented customer satisfaction. Said policy created even more denied automatic payments for my accounts, creating a snowball of unpaid bills. All from a company that is in the business of extending credit. This is unacceptable. So I will be canceling my relationship and moving to VISA. 
David Koontz, very unhappy customer.Here is the response I received from the Office of the President, US BANK Cardmember Service




One technique for losing customers is to make the very nature of your core business proposition an oxymoronic meme.  Let's use this US Bank - REI Credit Card issue as a case study.

The back story:  I've been a REI Credit Card user for around 10 years, I've built up a very good customer relationship, paying bills on time for those year, sure there may have been a slip through the cracks from time to time, yet my credit score reflects that I'm a very sound risk for credit.

So when a job transition happened in the sprint of 2016 there was much confusion with cash flow and various credit cards transition from one service vendor to another (seems as if Master Card is losing clients to VISA) and Costco moved away from Am Ex.  Lots of changes in the card industry.  These had various impacts upon my personal fincianal life...

Some few years ago I started moving auto pay bills to my REI card (US BANK) we loved the cash back rewards at one of our favorite shopping stores, REI.  So by 2016 almost every bill I get, from water bills to Amazon to Apple App Store to Netflix etc. is on the card.

Now in March, I missed the $30 min. payment to US BANK.  So in silence they blocked all debits and transaction to the card.  There was no communication to me about such a significant event.  However, I get plenty of alerts of various natures, such as payment due, minimal balances, large transactions, etc.  But, for unknown reasons explained by the Office of the President, they are just unable to communicate with customers about this type of event.

I've canceled the card.  Kinda hate to lose the REI relationship, but they have not responded to any inquiries either.  In today's credit industry there are plenty of reward programs to choose from and I've made other arrangements - did all the work to transition payments away from US BANK's card to a USAA Signature card.  Maybe I'll probe that system and see how they respond to a missed payment.

So what would US BANK needed to have done to keep a 10 year customer?  A simple alert - your account has been frozen because of late payment.  AND then been able to recognize a good customer and rectify the issue over the phone - by extending credit and reinstating the account with the promise of the check is in the mail.  After all their core business proposition is extending credit.


Full Disclosure:  I own MasterCard stock as well as Amazon, Apple, Costco, Netflix.

Categories: Blogs

the Failure Bow -or- how to love the experience of learning

Agile Complexification Inverter - Wed, 02/01/2017 - 18:23


I learned this technique from the facilitators of Language Hunting and Where Are Your Keys, they term the technique How Fascinating  and practice it quite a few times each game.



The purpose of the technique is to invert the physiology of failure into a learning moment to reflect upon what just went wrong and instead of cringing and curling up into a safe ball, we open up the body and the mind to learning and the experience of reflecting and allowing the universe to teach us something.

Try it a few times...





See Also:
The Failure bow -DeepFUN by Matt Smith
Go Ahead, Take a Failure Bow by Beth Kanter at HBR

TED Talk:  The unexpected benefit of celebrating failure
"Great dreams aren't just visions," says Astro Teller, "They're visions coupled to strategies for making them real." The head of X (formerly Google X), Teller takes us inside the "moonshot factory," as it's called, where his team seeks to solve the world's biggest problems through experimental projects like balloon-powered Internet and wind turbines that sail through the air. Find out X's secret to creating an organization where people feel comfortable working on big, risky projects and exploring audacious ideas.
Categories: Blogs

Run Functional (Coded) UI Tests in your VSTS Release Pipeline

Xebia Blog - Wed, 02/01/2017 - 18:08
Today I was trying to run some CodedUI test from my VSTS Release pipeline. The process is quite straightforward but there were some tiny catches I’d like to share with you Let me first show the pipeline I have created First of all, WINRM. It is always a search for me to see what’s wrong.
Categories: Companies

What Agile Managers Do: Podcast

Johanna Rothman - Wed, 02/01/2017 - 16:39

I had a conversation with Amitai Schleier last year. I told him how much I enjoyed Agile in 3 Minutes (the podcast). I learned something from each podcast.

He invited me to contribute one. Naturally, I chose management. My podcast, 34: Manage is up. If you like the podcast, you should check out the book, too. See

If you like the podcast, you should check out the book, too. See Agile in Three Minutes. In three minutes, I explain what agile managers do.

Teams can be agile, up to a point. If the managers are not ready to nurture the agile culture, agile won’t work. (See When is Agile Wrong for You?)

I hope you enjoy it the podcast and the book.

Categories: Blogs

Hybrid Methods are More Powerful than Kanban or Scrum

TV Agile - Wed, 02/01/2017 - 15:49
When teams decide to “go Agile” they invariably decide between Scrum or the Kanban Method. This is often because both Scrum and the Kanban Method provide a straightforward approach to get started. However, our experience has shown us that this leaves several options off the table. The reality is, one shouldn’t pick between two options. […]
Categories: Blogs

Becoming a Product Samurai

Scrum Expert - Wed, 02/01/2017 - 15:32
With Agile practices becoming more and more common, the call for Product Leadership has never been louder. Product owners are drowning in feature alignment and internal stakeholder discussions, slowed by technical and organizational complexity, crippled by a risk-averse company culture and focused on internal risks rather than market outcome. Long ago the Samurai learned that Agility in itself is not enough. Leadership comes from an unwavering vision, clear values and relentless exercise of martial practices (kata). What can we learn from them? What kata’s apply to Product Leadership? How can me make sure that we wield the sword of Agility in such a way that we don’t just make products right, but make the right products? This lightweight talk will offer practical solutions and insights on how to become a better Product Owner, Product Manager or anyone responsible for setting out a Product Strategy. Based on my personal experience as Product Manager, Director, Coach, Teacher (and martial artist). For it is our responsibility to save the world of crappy products and lead our teams like the Samurai. Video producer: http://topconf.com/
Categories: Communities

5 Gaps In Scrum

Leading Agile - Mike Cottmeyer - Wed, 02/01/2017 - 15:00

I recently spoke at a corporate community of practice event.  My session presented a useful model to identify indicators within a system to predict its failure. First, we started by applying the model to everyday systems everyone could relate to.  Next, I asked the attendees to map a system of their own. As I walked them through my model step by step, I used Scrum as my example system. Upon completion of the worksheet (see my completed sheet below), attendees were able to see if there were any “gaps” in their systems. The gaps provided an indication that a respective system was at risk of failure.

To clarify, on a delivery team level, I see the Scrum Framework as a solid method for managing product development. But what about Scrum in the context of the entire delivery organization?  Using both The Three Things You Need To Know To Transform Any Sized Organization and my model, I look at Scrum in a broader context. With that, I note 5 major gaps.

gaps in scrum

What are the 5 gaps in Scrum?

My model will segment any system into 5 areas: Clarity, Commitment, Ritual, Progress, and Habit. The gaps that I will note below are those things not mentioned in the Scrum Guide.

Gap 1: Clarity

What does the structure of the organization look like (Portfolio, Program, Product) above the Scrum Team? We need a shared understanding.  What does the governance of the organization look like (Budget, Dependencies, Risks, Quality,…) above the Scrum Team? What are necessary metrics and tools of the organization above the Scrum Team?  Some organizations are very large and heavily distributed.  How will you measure the health of the entire delivery system?

Gap 2: Commitment

In Mike‘s 3-things talk, he calls this accountability. Given the broad applicability of my model, I prefer to call it commitment.  Commitment can be any resource. So, what money and time may be required for Scrum training of all leadership and Scrum teams within an enterprise?  What money and time may be required for procurement, installation, and training of tooling used to manage and report on the health of the delivery system? Lastly, we need agreement from the Leadership team to follow the Scrum Framework (or more particularly respect that the Scrum team is following it).

Gap 3: Progress

As I noted in my post on Productivity Patterns, if you lack progress, you lose momentum. If you lose momentum (or should I be so bold to say velocity or throughput), you will lose commitment to the system. Those who are funding the efforts (those outside the Scrum team) need to know progress is being made in a way that is important to them.  What is the Time to Value?  Is the Scrum team predictable on a release level (Release Burndown/Burnup chart)?  Are we even building the right things? (Product Fit) Are we building things right? (Quality)

Gap 4: Rituals

Rituals can be event or meetings, as part of your system of delivery. First, let’s start with product vision.  Scrum teams have a horizon of a few weeks (the sprint).  Vision is viewed or realized in months, quarters, or years. Read the Scrum Guide and you won’t see Vision mentioned once.  Also absent from the the Scrum Guide is the notion of portfolio or release planning.  Unless you have a delivery capability that allows you to release at the end of every sprint, I can’t champion release planning enough.  In addition to that, good portfolio planning ensures we have a balanced system of delivery and ensures we have capacity to make commitments against a roadmap.

Gap 5: Habit

Given the rituals I outlined above, you should make it a habit to have periodic Vision Reviews, regularly scheduled Portfolio Planning/Reviews, and ensure you’re consistently doing your Release Planning.

Conclusion

I’m not suggesting you abandon Scrum. But after you look at the highlighted gaps I listed above, in a system of delivery larger than a single Scrum team, you should consider more than what is in the Scrum Guide.

The post 5 Gaps In Scrum appeared first on LeadingAgile.

Categories: Blogs

The Secret to Implementing Continuous Integration - CHEESE!

NetObjectives - Wed, 02/01/2017 - 11:50
Last time, I wrote about how Continuous Integration is like the Broccoli of the Agile world… everyone knows that it is good for them, but few really consume it.   The hanging question from that blog was, "How can we convince organizations to actually eat their Broccoli and implement real Continuous Integration?"   A friend of mine tells me that the secret to getting people to eat their broccoli...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Strategy Deployment and Impact Mapping

AvailAgility - Karl Scotland - Tue, 01/31/2017 - 17:14

I’ve had a couple of conversations in recent weeks in which Impact Mapping came up in relation to Strategy Deployment so here’s a post on my thoughts about how the two fit together.

An Impact Map is a form of mind-map developed by Gojko Adzic, visualising the why, who, how and what of an initiative. More specifically, it shows the goals, actors involved in meeting the goals, desired impact on the actors (in order to meet the goals), and deliverables to make the impacts. The example below is from Gojko’s website.

As you can see, an Impact Map is very simple, reductionist visualisation, from Goals down to Deliverables, and while the mind map format doesn’t entirely constrain this, it tends to be what most examples I have seen look like. It does however work in such as way to start with the core problem (meeting the goal) and allow people to explore and experiment with how to solve that problem via deliverables. This is very much in line with how I define Strategy Deployment.

Lets see how that Impact Map might translate onto an X-Matrix.

The Goal is clearly an Aspiration, so any relevant measures would neatly fit into the X-Matrix’s bottom section. At the other end, the Deliverables are also clearly Tactics, and would neatly fit in the X-Matrix-s top section. I would also argue that the Impacts provide Evidence that we are meeting the Aspirations, and could fit into the X-Matrix’s right-hand section. What is not so clear is Strategy. I think the Actors could provide a hint, however, and I would suggest that an Impact Map is actually a good diagnosis instrument (as per Rumelt) with which to identify Strategy.

Taking the 4 levels on an Impact Map, and transposing them onto an X-Matrix, creates a view which can be slightly less reductionist (although not as simple), and opens up the possibility of seeing how all the different elements might be related to each other collectively. In the X-Matrix below I have added the nodes from the Impact Map above into the respective places, with direct correlations for the Impact Map relationships. This can be seen in the very ordered pattern of dots. New Tactics (Deliverables) and Evidence (Impacts), and possible more Aspirations (Goals), would of course also need to be added for the other Strategies (Actors).

Even though this is a very basic mapping, I hope its not too difficult to see the potential to start exploring what other correlations might exist for the identified Tactics. And what the underlying Strategies really are. I leave that as exercise for you to try – please leave a comment with what ideas you have!

This post is one of a series comparing Strategy Deployment and other approaches.

Categories: Blogs

Building, testing and deploying precompiled Azure Functions

Xebia Blog - Tue, 01/31/2017 - 17:00
Azure functions are great to build small specialized services really fast. When you create an Azure Functions project by using the built-in template from the SDK in Visual Studio you’ll automatically get a function made in a CSX file. This looks like plain old C# but in fact it is actually  is C# Script. When
Categories: Companies

We Tried That, and it Didn’t Work

Leading Agile - Mike Cottmeyer - Tue, 01/31/2017 - 16:00

I once used a hammer and it didn’t work. Therefore, people should never use hammers.

If you find that reasoning satisfactory, then you may also appreciate the following statements:

  • We tried pair programming and it didn’t work.
  • We tried test-driven development and it didn’t work.
  • We tried Scrum and it didn’t work.
  • We tried User Stories and they didn’t work.
  • We tried Personas and they didn’t work.
  • We tried Specification by Example and it didn’t work.
  • We tried continuous delivery and it didn’t work.
  • We tried baseball and it didn’t work.

There is a notion of logical validity. An argument may be logically valid even it if is untrue or unprovable. Validity is a question of structure. The following structure and example are taken from the Rational Wiki page about logical validity.

The model:

  • If X then Y
  • X
  • Therefore, Y

And the example:

  • If there is creation there must be a creator.
  • There is creation.
  • Therefore, there is a creator.

So, is there a creator? Maybe. We can’t tell just by looking at the sample argument. We can tell that the argument is structurally valid.

Logical validity is prerequisite for an argument to be considered logically sound. To be sound, an argument must be valid; but a valid argument is not necessarily sound.

With that background, what do you think of the opening assertion of this post? “I once used a hammer and it didn’t work. Therefore, people should never use hammers.”

I think the argument is logically valid:

  • If hammers don’t work, then people shouldn’t use them.
  • Hammers don’t work.
  • Therefore, people shouldn’t use them.

But I question the logical soundness of the argument. The part of the statement that stands out for me is the phrase “it didn’t work.” What is the definition of “it works?”

My first impulse is to consider the possibility that the hammer did not function properly as a hammer. This could occur due to a fault in the design or manufacture of the hammer. Even so, such a fault would not condemn all hammers categorically. By this definition, as long as a hammer does what hammers normally do, then it “works.”

If we assume the hammer did what hammers normally do, then what might the speaker have meant by saying “it didn’t work?”

Most likely, they meant they did not achieve the result they expected or wanted when they used the hammer. That may be so, but is it reasonable to conclude from that experience that hammers are categorically useless?

A hammer is a kind of tool. A tool is something that aids in accomplishing a task. Hammers are designed to aid people in accomplishing the task of driving nails.

If “it didn’t work” means “I didn’t accomplish my task,” then is the tool to blame? Setting aside faults in design or manufacture, we can assume a hammer always does that which hammers are designed to do: They apply blunt force to a target. We can further assume that a hammer has no goals, hopes, fears, intentions, or ulterior motives. It just strikes whatever you swing it at, whether or not you’ve selected an appropriate target and whether or not you’ve swung the hammer with skill. To say that a hammer “didn’t work” is meaningless.

One can also consider the following to be tools, in the sense they are things that aid in accomplishing tasks:

  • pair programming
  • test-driven development
  • Scrum
  • User Stories
  • Personas
  • Specification by Example
  • continuous delivery

If we want a tool to help us accomplish a task, it seems to me we need to follow a two-step process:

  1. Choose the right tool for the job
  2. Use the tool properly

Otherwise, it won’t “work.”

The post We Tried That, and it Didn’t Work appeared first on LeadingAgile.

Categories: Blogs

Sketchnoting – a free guide

Growing Agile - Tue, 01/31/2017 - 10:38
Categories: Companies

Knowledge Sharing


SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.