Skip to content

Feed aggregator

The Tweets You Missed in January

Sonar - Mon, 02/06/2017 - 11:09

Here are the tweets you likely missed last month!

SonarQube 6.2 released: read the news and see in it screenshots! https://t.co/MaLzAnorc9https://t.co/qhVuMdnvSD pic.twitter.com/Lqvc7IklFf

— SonarQube (@SonarQube) January 10, 2017

Governance 1.2 dissociates overall health of an application portfolio and risk identified on its projects https://t.co/Ztt9a0AMQ4 pic.twitter.com/bVBhkKal1p

— SonarQube (@SonarQube) January 12, 2017

SonarPython 1.7 brings support for Cognitive Complexity https://t.co/r5Mi3ga0jw pic.twitter.com/1kwBUvaoVR

— SonarQube (@SonarQube) January 27, 2017

SonarC++ 4.4 Released: SonarLint for Eclipse CDT support, improved dataflow engine and 4 new ruleshttps://t.co/eQRS02gGN3 pic.twitter.com/MFxomdHCXF

— SonarQube (@SonarQube) January 12, 2017

SonarJS 2.19 Released: 14 new rules, including 2 rules detecting invalid calls to built-in methods https://t.co/RaZOecudjn #javascript pic.twitter.com/CvENmeD882

— SonarQube (@SonarQube) January 12, 2017

Detecting Type Issues in #javascript with SonarJS, see https://t.co/ugos9C3uXf pic.twitter.com/R2RTEt9jQ3

— SonarQube (@SonarQube) January 11, 2017

SonarLint for IntelliJ 2.7 shows issues context and highlights corresponding locations https://t.co/wvnnyVEjA4 pic.twitter.com/GMGBO3Vvwx

— SonarLint (@SonarLint) January 31, 2017

Categories: Open Source

Targetprocess Mobile for iOS Release 3.2: Entity view redesign

TargetProcess - Edge of Chaos Blog - Mon, 02/06/2017 - 09:10

We finally did it! A new release for our iOS app is now available in the App Store.

Entity view

We’ve changed the way that entity details views are displayed on Apple devices. These views are now much better adjusted to iPhone and iPad screens, so it’s much more convenient to use Targetprocess on your phone or tablet:

card-view

Custom Fields on entity view

You can now view and edit an entity's Custom Fields from its details view:
custom-fields

Some other useful improvements include:
  • The ability to open links from Description and Comments
  • A "share" action for Attachments
  • A progress bar for Release, Iteration, Team Iteration, and Project entity views
  • A state selector for Projects
  • Multiple teams selector on entity details views.
  • Projects list on Release views

If you have anything you want to share with us, use the Feedback form in the app's 'Me' tab, or shoot us a message at mobile@targetprocess.com.

Click here to download the iOS app.

Categories: Companies

Top 5 Ingredients for developing Cloud Native Applications

Xebia Blog - Mon, 02/06/2017 - 08:50

Introduction Cloud Native Applications is a trend in IT that promises to develop and deploy applications at scale fast and cost-efficient by leveraging cloud services to get run-time platform capabilities such as performance, scalability and security out of the box. Teams are able to focus on delivering functionality to increase the pace of innovation.  Everything […]

The post Top 5 Ingredients for developing Cloud Native Applications appeared first on Xebia Blog.

Categories: Companies

Being an Agile Security Officer: pwn the process

Xebia Blog - Sat, 02/04/2017 - 21:15

This is the third part of my 'Being an Agile Security Officer series'. As mentioned in my previous blog, in the Agile world the Product Owner is the person who translates business and customer desires into work items for the teams. To do this, product owners have several techniques and means at their disposal. In […]

The post Being an Agile Security Officer: pwn the process appeared first on Xebia Blog.

Categories: Companies

Integral Model for Agile Coaching

Growing Agile - Fri, 02/03/2017 - 10:30
We were introduced to the Integral Model in Lyssa Adkins’ Coaching Agile Teams course. It’s a quadrant model that helps you look at teams you are coaching through 4 different lenses: Mindset, Practices, Relationships and Environment.  The axes are intangible to tangible (X) and singular to collective (Y). So, environment is in the tangible and […]
Categories: Companies

Agile Leadership Training

Notes from a Tool User - Mark Levison - Fri, 02/03/2017 - 04:52

cal_banner_960x260

-->

Agile Pain Relief Agile Leadership Training — Giving leadership and management the tools and techniques to enable Agile within their organization

With the growing adoption of Agile, there is a need for a holistic approach for organizations to employ Agile throughout all aspects of business, rather than within specific teams. Expanding Agile methods from their traditional applications as development or product management tools into all areas of the organization requires a new set of skills in the management suite: Agile Leadership. Agile Leaders and Agile Leadership empower their organization from the top down to:

  • Instill and practice Agile values, methods, and metrics at the organizational level
  • Enable teams to deliver more customer value
  • Remove barriers to team success
  • Foster creative solutions

This three-day, hands on course led by Certified Scrum Trainer (CST) Mark Levison is targeted towards leaders, influencers, and managers within organizations that employ — or are planning to employ — Agile. Participants will learn core Agile concepts, processes, and practices, and how Agile can be used as a tool for organizational change to increase productivity and improve employee and customer satisfaction.

The Agile Pain Relief Advantage Small Class Size in Your City Agile Pain Relief limits class sizes to ensure a high quality learning environment with more opportunities to address your questions and concerns. Local training classes mean you meet and network with other professionals near you. On-site, private training also available. In-person and Interactive Direct learning tailored to each class and student. No canned PowerPoint presentations or webinars. Live instruction from Certified Scrum Trainers (CST) and group exercises modelled on Agile methods. Hands-on Applications of Scrum Methods with Agile Theory Practical examples and exercises using Scrum and Agile principles teach you how to adapt and practice Agile methods in your projects. Online Course Materials and Support Course attendees receive electronic copies of all seminar materials (including free updates to course materials as they become available) and exclusive access to Mark through Agile Pain Relief’s LinkedIn group.

*Certification Pending
** Courses available Q1 2017

Categories: Blogs

LeanAgileUS 2017

AvailAgility - Karl Scotland - Thu, 02/02/2017 - 17:58

Lean Agile US

LeanAgileUS is taking place in Fort Lauderdale, Florida on February 27-28th. It has a real mix of great speakers and content, covering all aspects of Lean and Agile including Scrum, SAFe, Kanban, DevOps amongst other topics. I expect it to be an event where people come together for dialogue about different perspectives. I hope to hear more of “That’s interesting, tell me more” and less of “That’s wrong, and here’s why“.

My contribution will be twofold.

Firstly I have a talk on the Monday entitled “Good Agile / Bad Agile: The Difference and Why it Matters”, which you may recognise as the title of a recent post. I will be exploring some of those ideas in more detail. Here’s the abstract:

Stories of Bad Agile are common, where Agile is a local and tactical implementation, resulting in failed projects and initiatives. Businesses don’t get the results they had hoped for and Agile gets the blame for not working. Good Agile, however, is possible when it is directly and explicitly related to a business strategy. Thus Agile needs to be deployed strategically, with a clear diagnosis of the critical problem or opportunity faced, guiding policies on the approach to addressing the diagnosis, and coherent actions to implement the guiding policies. This talk will show how this approach can lead to Good Agile which is evolved through experimenting as opposed to Bad Agile being instantiated by copying.

Secondly I have a half day workshop on the Tuesday entitled “Enterprise Agility with Strategy Deployment”. This will be an opportunity to learn more about the X-Matrix, experience the process of creating one, and understand how to use it alongside other A3 templates. Here’s the abstract:

Strategy Deployment is a style of organisational improvement that engages the entire workforce in figuring out how the business can survive and thrive. This course will introduce Strategy Deployment using a framework called the X-Matrix – an A3 format which concisely visualises the alignment of results, strategy, indicators, and tactics on a single sheet of paper. With this approach, a transformation can be viewed as a form of Catchball, a Lean process where ideas are passed around an organisation as teams collaborate to experiment and discover solutions. In this way, solutions emerge from the people closest to the problem, rather than being defined and dictated by management.

The whole event is great value for money. Register soon as I’m sure it will sell out!

Categories: Blogs

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 his greatest poems that is as relevant now as it was then.

I first read this during my freshmen year in college (amongst the rest of his poetry) and the passages below really hooked me in.

Say, who are you that mumbles in the dark?
And who are you that draws your veil across the stars?I am the poor white, fooled and pushed apart,
I am the Negro bearing slavery’s scars.
I am the red man driven from the land,
I am the immigrant clutching the hope I seek — 
And finding only the same old stupid plan
Of dog eat dog, of mighty crush the weak.I am the young man, full of strength and hope,
Tangled in that ancient endless chain
Of profit, power, gain, of grab the land!
Of grab the gold! Of grab the ways of satisfying need!
Of work the men! Of take the pay!
Of owning everything for one’s own greed!I am the farmer, bondsman to the soil.
I am the worker sold to the machine.
I am the Negro, servant to you all.
I am the people, humble, hungry, mean — 
Hungry yet today despite the dream.
Beaten yet today — O, Pioneers!
I am the man who never got ahead,
The poorest worker bartered through the years.

Enjoy!

Let America Be America Again

Let America Be America Again was originally published in James Carr on Medium, where people are continuing the conversation by highlighting and responding to this story.

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 […]

The post How to create your own Lint rule appeared first on Xebia Blog.

Categories: Companies

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

Knowledge Sharing


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