This post is a synthesis of two posts I originally published on my other blog "unRelated".

One of the key foundations and most attractive principle of Agile or Lean methodologies is that  "Everyone can help each other remain focused on the highest possible business value per unit of time".

I am certainly a strong supporter of that principle. However, value is often difficult to assess, I would actually argue that it is easier to identify what has less or little value, but what we think as valuable can potentially lead to many false positive, or simply be "business-as-usual" and hide the broader structure of the solution. 

"User Stories" are the corner stone of identifying and delivering value:

An argument can be made that the user story is the most important artifact in agile development, because it is the container that primarily carries the value stream to the user, and agile development is all about rapid value delivery.

In practice, very few people focus on the benefits part of a user story. All user stories I see are either what we used to call "requirements" (just phrased slightly differently but isomorphically) or "tasks" needed to advance the state of the project.

However, there is a fundamental flaw in the construction of user stories, even when they are properly written, because they somehow make an assumption about the shape of the solution, and drive the author to turn almost immediately in solution mode, leaving no room for creative and out-of-the-box thinking.

Let's compare the metamodel of a User Story and to the formal definition of a Problem. The metamodel of a User Story looks like that (using the BOLT notation):

As a <role> I want to <action> so that <benefit>

us-model

I define a problem formally as a non existing transition between two known states [1],  the metamodel of a problem looks like that:

pb-model2

 

A solution is a way to transition between these two states. Please note that both the actors and the actions are part of the solution:

sol-model

 

This is where the problem lies when using User Stories, you are specifying the requirements with the solution in mind. There is, of course, a general relationship between some of the actors and entities of the system with the "start" and "end" states of the problem. The problem states are always defined in terms of their respective states (possibly as a composite state), but it is a mistake to think that the actors and entities that perform the actions, as part of the solution, are always the same as the actors and entities related to the (problem) states.

Hence, an action is solution centric and should not be part of the problem definition. As soon as you pick one, you have put a stake in the ground towards the direction you are going to take to solve the underlying problem. The other issue is that the start and end states are never clearly identified in a user story leading to confusion in the in the solutioning and verification process, since the problem is not defined with enough precision. Benefits could sometimes align with the target/desirable state, but the definition is often too fluffy and more goal centric, not effectively representing that (problem) state.

Ultimately, the relationship between problems and solutions is a graph (states, transitions as problems, actions as solutions), and this is where the coupling between the problem space and the solution space at the User Story level becomes unfortunate. This means that User stories cannot be effectively nested and clearly cannot fit in hierarchical structures (which is common to most Agile tools I know). This problem is quite accute as teams struggle to connect business level user stories and system level or solution level user stories. The concept of having a single parent directly conflicts with the possibility of having multiple possible transitions into a single state and decomposition principles where the same problem appears in the decomposition of several higher level problems. 

I feel that distinction is profound because we can now clearly articulate:

a) the problem statements with respect to each other (as a graph of states and transitions)

b) we can articulate the solution in relation to the problem statements

c) we can articulate the verification (BDD) in relation to the problem and solution [2]

d) we can actually articulate the Business Strategy [3], the Problem Statement, the Solution and the Verification with the same conceptual framework

e) derive the Organizational IQ from the problems being solved on an every day basis

To the best of my knowledge none of these articulations have been suggested before and no one has ever provided a unified framework that spans such a broad conceptual view from the Business Strategy to the Verification. In the proposed framework the business strategy is simply a higher level and specialized view of the problem and solution domains, but using the exact same semantics (which are described here). In other words the enterprise is a solution to a problem, which is a composition of smaller problems and more fine grained solutions, etc. This has an extremely important implication for the execution of the strategy because now both the Strategy and its Execution are perfectly aligned, at the semantic level: the strategy, problem, solution and verification graph represent a map that everyone in the organization can refer to. 

To take advantage of this new conceptual framework. I suggest that we make a very simple and easy change to Agile and replace "user stories" by "problem statements". Each problem must be "solutioned", either by decomposing it into simpler problems or solutioning it directly. Value can still be used to prioritize which problems are addressed first, that part of the Agile and Lean movement is very valuable, so too speak, but the focus on problems and solutions opens a new flexibility in how we handle the long range aspects of the solution while enabling the highest level of creativity and ultimately a direct articulation with the IQ of the organization. 

As problems are decomposed, we will eventually reach a point where the subproblems will be close to or isomorphically related to the solution. But it would be a mistake to not clearly delineate the problems from solutions, simply because at the lowest level, they appear isomorphic. 

If we start drawing some BOLT diagrams, a problem lifecycle can be defined as:
problem-lc

The fact that the lifecycle is pretty much identical as the one of a user story enables most of the Agile processes and tools to work nearly unchanged.

You may want to know "How do I write a Problem Statement?". Personally, I don't like canned approaches. Oviously here, the mere definition of the two states (low value and high value) is enough to describe the problem. If a solution already exists (i.e. it is possible to transition between these two states) you may want to describe some characteristics of the new solution. I googled "How to write a Problem Statement?" and I felt there was already a good alignment betweent the results and the abstract definition provided above. For instance:

We want all of our software releases to go to production seamlessly, without defects, where everyone is aware and informed of the outcomes and status. (Vision)

Today we have too many release failures that result in too many rollback failures. If we ignore this problem; resources will need to increase to handle the cascading problems, and we may miss critical customer deadlines which could result in lost revenue, SLA penalties, lost business, and further damage to our quality reputation. (Issue Statement)

Here we see two states for the releases: initial state (low value) tested, and the high value state (in production). There is also an undesirable state (failure) that the new solution will prevent reaching. For me the most important thing is that the problem statement must avoid at all cost to refer to the solution. Even if the people specifying the problem statement have an idea about the solution, they should capture it separately.

This new focus on problem & solution provides a rich conceptual framework to effectively organize the work of a team. After all, we have been innovating, i.e. creating solutions to problems, for thousands of years, so it is no surprise that our vocabulary is quite rich. Here are a few concepts that could be used:

Goal: a goal is not a problem, but you often need to solve problems to reach goals, so it's important to keep them in mind

Fact: a fact often constrains the solution, so they need to be clearly surfaced and accounted for

Assumption: assumptions are very important because they also constrain the solution, but in a more flexible way. Assumptions can be changed, facts generally cannot.

Statement: the problem statement is what physically replaces the user story.

Hurdle: During the decomposition of a problem, hurdles might be identified, they are not a problem per say, but they impact the solution. It could be for instance that a resource is not available in time to meet the deadline.

Snag: A problem can be downgraded to a snag as the solution is obvious to the team and represent a low level of effort. It can also be a small unexpected issue, that need to be quickly resolved.

Dilemma: A problem can be upgraded to a dilemma, when several solutions are possible and it is not clear which one to chose

Setback: The team can suffer a setback when it thought it had found the solution but it didn't, or could not find a solution and need to reassess either the problem or the approach

On the solution side, we can also capture different elements and stages of the solutioning process:

Answer: Findings related to a question raised in the problem statement.

Result: A validation that the solution conforms to a Fact

Resolution: The choice made after reaching a dilemma

Fix: a temporary solution to a problem or a snag to make progress towards the solution to the greater problem

Development: An element of the solution, usually the solution to a subproblem or a snag

Breakthrough: The solution found after reaching a setback

Way out: A solution was not found, nevertheless, the project reached a satisfactory state to meet some or all of the initial goals

...

From a management perspective. The Solution or Delivery Manager can escape the bureaucracy that Agile has created. Ironically, moving stickers around is a zero value activity, with zero impact on the organizational IQ. The solution manager can and should be responsible for the IQ of the project, which rolls up and benefits from the IQ of the organization. It should keep track of the elements that are incorporated in the solution as problems are solved. It should encourage team members to be creative when necessary and to shamelessly adopt existing solutions when it makes sense. It should help resolve dilemmas and push for breakthroughs.

The PMO organization becomes the steward of the Organization's IQ.

As we define problems and solutions in terms of entities, state, transitions and actions, the BOLT methodology provides a unified conceptual framework that spans from Business Strategy to Problem and Solution Domains to Verification (BDD).

To summarize,

1) We have provided a formal model of a problem and a solution, and how they relate to each other

2) This formal model offers the ability to compose problems and solutions at any scale, over the scope of the enterprise

3) Problems and Solutions can be composed from Business Strategy down to Verification

4) We suggest that Agile methodologies replace User Stories by Problem Statements

5) With the renewed focus on "problems", we can also integrate the work of Prof. Knott on Organizational IQ in the whole framework

Last, but not least, decoupling problem definition and solution yields a tremendous benefit in the sense that both can evolve independently during the construction process. 

_______________________________________________________________________________

[1] For instance, you build a vehicle, obviously you want to car to transition to the "in motion" state. Different "actions" will lead to the vehicle to reach that state (a horse pulling, an engine, transmission and wheels, a fan, ...).

[2] BDD Metamodel (Scenario):

bdd-model

 

[3] Living Social Business Strategy mapped using the same conceptual framework (Source: B = mc2)

lifecycle

This is cross-post from my new blog "unRelated"

In the chapter "A world in motion" that we made available, we explain how the Postal Service could reinvent itself and thrive as the logistics engine of the Platform. It seems that they are already well on their wayto take advantage of that opportunity:

The Metro Post service comes on the heels of a similar test by Wal-Mart, which earlier this week said it planned to offer same-day delivery in 10 cities this holiday season. Meanwhile, London-based Shutl received $2 million in funding from UPS in August for a same-day package delivery service, while eBay also is experimenting with the concept.

How will this seemingly unrelated move can change the world as we know it? Logistics is a key enabler of rCommerce (Relationship Commerce). It supports the relationships we have with our environment. In B = mc2, we explain that Philips could probably double their replacement part revenue for their SoniCare line, while making it far more cost effective, by simply providing a mobile app with a single button "Send me a toothbrush".  Before the Platform, nobody knew I had a SoniCare toothbrush. Philips didn't know, the Postal Service didn't know, even the store where I bought it didn't know.

With rCommerce, we sell to the "relationship" be it the relationship between people, or the relationship between people and the things in their environment.

So, how will Same-Day-Delivery change our world?

a) Replacement parts are cool: for instance, our everyday appliances will evolve to have a lot more replacement parts instead of being designed to be thrown away as soon as something fails

b) Everything that can be ordered from an app will disappear from the shelves leaving a lot of empty space, these shelves will move to the Postal Service warehouses

c) Retail Stores will reconfigure themselves to be either a catalog (show room) or an inventory that the Postal Service cannot handle easily. Retail couples three processes: catalog (the shelves), inventory and order/payment. The Platform will decouple them and Order/Payment will be handled directly with the customer mobile device, because this is the easiest way to establish the relationship between the customers and the products they buy. All the mobile terminals that you see in an Apple store or at Sears for instance, will quickly be replaced by an app running on your own device.

Make no mistake about it, rCommerce will reshape the retail landscape as we know it.

I would not be surprised if one day we see the emergence of "continuous delivery"...

Ganesh Prasad and Eric Newcomer are probably one of the two people I respect the most in the SOA community. I had the privilege to work on WS-CAF with Eric and that standard forged most of what I think is right on SOA. I also had the pleasure to meet Ganesh in Sydney in 2009.

That being said I am appalled that in 2012 we are still debating the question Eric asked to Prasad at QCon NY:

"Where I was working previously at Credit Suisse, we had a long debate about sharing and how to share code; we had done some analysis to find there was a lot of overlapping and duplicate functionality in the applications and we could rationalize those down to perhaps a single function that would be shared, but then we had a big question of how should we share it the best way; should we share it with libraries, should we put an abstract interface on it, how should we do it; what are your thoughts there? "

This is an excellent question, one that has haunted and apparently still haunts our industry. So for the record I would like to explain why it is so hard to reuse code and why and how it could be made much easier.

The main consideration you have to make to answer that question is to realize that every concept (software agent, information entity, physical thing, document...), absolutely everything, no matter what it is, has a lifecycle. Unfortunately for us, computers "compute" and do not really care about the states in which "things" are, hence there is nowhere in computer programming languages the notion of state and lifecycle. This is one of the greatest tragedy of software engineering.

I wrote many posts on that concept, but let me reiterate it here one more time. Here is a lifecycle, the lifecycle of stock order (as in stock market). Every state can be understood by any developer and most of them can code easily all the actions that will correspond to each transition on that diagram. That is the code that Eric is talking about, the one that we want to reuse for different situations, for instance retail vs private brokerage. 

 

The fundamental problem to reuse is the lifecycle itself, the lifecycle is often, if not always different for every context, making it impossible to reuse. People look at reusing operations, blindly, without understanding there is an inherent lifecycle. They say I have a "createStockOrder" operation (POST StockOrder in REST BS), I have a submitStockOrder, a cancelStockOrder, ... check, check, check, retail and private brokerage should be able to use the same operations. Well, a typical problem between private and retail is that the funds are available at different times. Retail operations demand that funds be ready and alocated when the order is submitted, when private activities often involves reallocating funds which are not yet settled at the time the order is taken. As long as the transaction can be settled properly, private banking operations can operate without the funds.

So in general, two different contexts, in which the "service" will be used will require variations on the lifecycle implemented by the service. It is often trivial to align a lifecycle to support multiple contexts, it is just a mater of adding states and transitions. But no, our industry went the other way, it came up with REST, it said, you can't reuse the actions, let's make them disappear, voila. No lifecycles, no actions, everything is now burried under a big pile of CRUD. You want to reuse something? You are on your own, PUT, POST, DELETE, ... that's all you get. 

So no Ganesh, this is not a problem of "smaller components", "chunks", "coupling" or "cohesion" ...  this is simply a problem of lifecycle and variants of the lifecycle based on the context of utilisation. If the lifecycle is the same, great, you can reuse it, if the context requires a different one, you have to augment the existing lifecycle to match two or more contexts. The common parts of the lifecycle (states and actions) will be "reused", the ones that are specifically used for supporting a particular context cannot be reused.

No, it is not a dependency question, it is not a blueprint, it is not about breaking, reuse, ... it is about lifecycle. I am not quite sure why it is not possible to have an honest and serious discussion about the relationship between SOA, reuse and lifecycles. That has puzzled me for quite some time actually. 

Ah ... I nearly forgot, and "reuse" happens the other way around. It is not the new context that is using the old lifecycle, it is the the old contexts which are reusing the new updated lifecycle. 

How hard can it be to understand that?

 

Jack Greenfield and I have started the process of publishing a new book B = mc2

A sample chapter ("A world in motion") is now available. It talks about how "the Platform" came about and explores where it could go.

“The Platform” is creating a tectonic shift that could be compared to the invention of concrete, the Darby Furnace, the transport of electricity or container shipping.

Market structures and Industry boundaries are about to shift in unforeseeable ways, and every space of the economy should be considered, today, uncontested. There are simply no amount of historical patterns, cost cutting, dashboards, 4 square frameworks or even sustainable evolutions that can prepare an organization to transition into that new world.

The book itself is about a new Business Strategy Methodology well suited to successfully transition your business to the Platform.

We have started a new blog "unRelated", http://www.b-mc2.com/feed

If you have any feedback, Jack Greenfield and I would be happy to hear it.

We have some exciting news to report on Canappi's mobile back-end capabilities. We have used MongoLab MongoDB's hosted service for a number of projects and we have made it even easier to create data services for mobile apps using MongoLab.

All you have to do is create a data model such as that one (A job application data model ): 

 

Canappi generates a new MDSL file which contains 800 lines of a mobile application which can List, Detail, Create, Update and Delete any of the entities of the data model. Before you would have had to write these 800 lines by hand pretty much:

And voila, you can generate the Objective-C code for the corresponding iPhone / iPad application, including the login screen for the entities that require login (do not forget to create a hireme database in MongoLab and update the API key):

And ... well if you wanted to deploy your app using PHP/MySQL or WSO2 Data Services Server, the same data model definition enables you to do just that !

Canappi is well positioned to help you create dual-resolution, dual factor, dual platforms apps. We already supported dual screen resolution for the iPhone / iPad Universal Binary model. We just released today an update to our Eclipse plugin and code generator that fully supports programmatically iPhone 5 screen resolutions. We extended our coordinate system to model a shift that is applied to the current coordinates when the app is running on an iPhone 5.

text name (10,60,100,30 + 0,10,0,2) { ... }

This means that the name textfield will be displayed at (x=10,y=60) on iPhone 4 (with a width of 100 and height of 30).  On the iPhone 5 it will be displayed at x=12, y=70 with the same width and a height 32.

With that approach you can even bring "off screen" controls within the view bounds when the view is displayed on an iPhone 5:

text name (-200,60,100,30 + 220,10,0,2) { ... }

So this is what you do with a single MDSL file, yes, dual resolution, dual form factor and dual platform.

 

320x480

(iPhone)

Retina Display

(iPhone 4)

640x1136

(iPhone 5)

1024x768

(iPad)

Retina Display

(iPad)

iOS yes yes yes* yes yes
Android  yes**   N/A  yes (up to 1280x720)  to be released soon  N/A

*to activate your project to work in an 4" size, you need to add a PNG file to your project named: Default-568h@2x.png. Here is a blank one you can use for testing. This file will automatically used as the 4" version splashscreen. It's hard to believe that Apple could be that clumsy, but so far this is the only way I have seen to get the app use the full 4" resolution.

**On Android we use DIP and we have experienced a really good support of various screen resolutions, from 320x480 to 1280x720, using a positioning space of 320x480, in other words, in DIP mode, Android adapts the positions and sizes of the controls defined using a coordinate system of 320x480 to fit well the current resolution of the screen. This would not be true of graphic files and it is recommended to provide resources that match the phone resolutions from 320x480 to 1280x720.

What all this means is that all of our customers can rapidly migrate their applications to support all these resolutions within a single MSDL file that contains:

  • two independent layouts (one per form factor phone /table).
  • the shifts to be applied for larger screen resolutions. 

This is what the MDSL file would look like:

//A single definition file to support 8 different runtime options

layout myTabletLayout {

text name (10,60,100,30) { ... }

}

layout myPhoneLayout {

text name (10,60,100,30 + 0,10,0,2) { ... }

tablet myTabletLayout ;

}

This is a tremendous validation of our approach and programming model.

We'll be releasing support for ARC and some key function of iOS 6 with our release 1.4 early October.

<< 1 2 3 4 5 6 7 8 9 10 11 ... 21 >>

Search

 Subscribe







blog engine