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>
I define a problem formally as a non existing transition between two known states , the metamodel of a problem looks like that:
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:
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 
d) we can actually articulate the Business Strategy , 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.
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).
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.
 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, ...).
 BDD Metamodel (Scenario):
 Living Social Business Strategy mapped using the same conceptual framework (Source: B = mc2)
The purchase of Instagram by Facebook is no less than an attempt to redefine the landscape of our industry: today, you are either an app, a service or a platform.
For instance, RIM will become an "app". No disrespect, it can be a formidable app, opening the doors to the Enterprise to an Apple or a Google, but the window of opportunity for RIM to be a platform is gone. In this new world, search is an app which sets the search context with a high degree of precision (yelp, UrbanSpoon...), ads is a service and the Worn out WWW amounts to the Yellow Pages (paper HTML edition).
... and maybe (always smiling) Amazon. The problem with Amazon is that they'll have to choose between being a commerce platform (and compete with WalMart) or an industry platform and play with the big boyz. I don't think these two things work well together and eventually Amazon will return to its commerce roots mainly because of the lack of social capability. Amazon is a formidable company, but they are too late to the game, they have no money in the bank to acquire what they need to compete and they are burdened by a big legacy business, deeply rooted into the Web. As (Microsoft), Google and Apple know, there are only so many social networks that can fuel a healthy platform. Most likely Amazon will become a substrate to support services with AWS, and of course, an "app", the kindle, assuming the platform guys leave these holes open (far from a given).
Yet, Amazon was a decisive factor in establishing the architecture of the platform. It reinforced the power of the vertical integration pioneered by Apple. If you come with a great device or set of devices, and an app store, customers will line up. Something that Google is still struggling to emulate with an open ecosystem, and I am not even talking about Microsoft. In other words, it is not the number of devices you sell that counts, it is the the numbers of end-users actively using the platform to buy digital goods, interact, store their stuff... If you doubt it, just ask Nokia ...
If the social integration is pretty much a given, the game gets really interesting when it comes to the vertical integration. As we have seen with Apple, customers don't see "choice" (or price) as a competitive advantage. People want simple product lines with products they can actually use, with clear and real innovation at each cycle, built by thoughtful product teams: selling incremental junk is no longer an option (as HP painfully learned). And yes, TV or Game consoles will be engulfed in the platform. How could the platform guys leave them on the table? Any device that can run an app will be vertically integrated in the platform (or replaced by one).
My best guess is that:
- MS/FB will partner strongly with or even acquire Nokia and HP.
- Google/Motorola will swallow HTC and/or LG, possibly bring Dell in its ecosystem
- Apple ... huh ... will buy Twitter, and RIM for its Enterprise App
Samsung could team up with Amazon, but most likely it will become the component provider of the platform guys. SONY's, Nintendo's and HP's troubles simply show that there is no more room for Independent Hardware Vendors: you are either a (vertically integrated) platform or you supply the platform with components, no, not even devices (I mean other than speakers and power adapters). The touch points to consumers are going to be completely locked down, not one will be left open.
Even Telco providers will be suppliers to the platform guys, with the Skype/Hangout/Facetime apps being the new face of telephony.
The interesting thing here is that unless social networks are just a fad, MS/FB is the most likely winner of that game. There is a large probability that MS/FB/NOK/HP could take on 80% of a vertically integrated, consumer oriented market. Even Ballmer could pull that off and retire on a real visionary success. Google will lose that game (this is not an engineers game, let alone using corny "Web" paradigms and UX, in any case they will take the decision to move to a vertically integrated model too late without any muscle behind it). Apple will take on a 20% "think different" crowd. Apple is not aggressive enough to win that game, they'll look back to their $100 B in the bank and ask themselves, if they could have used it more "wisely".
Facebook spent a billion, not to buy Instagram but to hold our industry by the balls. With its IPO behind, it will call the shots for years. And yes ... Zuckerberg is next CEO of "The Platform".
Fascinating times ... it's a shame that Steve is no longer with us.
06/18/2012: Microsoft announces the "Surface"
07/04/2012: Google Jelly Bean is a game changer. Google seems to finally get it, UX is key to win this game. I may be wrong after all, Microsoft may never be able to catch up. If Microsoft continues to mess up on the Mobile OS side over the next 6 months, there will be no Microsoft in the Mobile space moving forward.
07/06/2012: Amazon is planning to launch its own smartphone.
07/16/2012: Google (Motorola) is launching the Atrix HD.
07/20/2012: Microsoft reports a big jump in Skype usage, up 50%
07/23/2012: Amazon plans 6 new Kindle variants.
07/26/2012: Facebook works with HTC on its own smartphone
07/28/2012: Microsoft is in trouble, that may well be the statement that signals the decline of the company: Microsoft CEO Steve Ballmer has sought to downplay the notion of Surface competing with partners, recently calling the device “just a design point.
7/31/2012: Details on Microsoft's plans to move to a vertically integrated model
8/20/2012: It looks like Microsoft does not aim at partnering / merging with Facebook, they sold 20% of their stake right after the IPO, that's kind of a shame, without even the shadow of a social network, they will have a hard time getting there. Unless their secret weapon is to make Yammer a general purpose social network.
8/22/2012: "The Platform" is on Amazon's Navigation Bar: App Store, Storage, ... Critically missing is the social network component.
9/06/2012: Amazon unvails the new Kindle, "People don’t want gadgets anymore, says Jeff Bezos, they want services that improve over time. Kindle Fire is a service. It greets you by name. Comes out of box with content preloaded, makes recommendations."
9/06/2012: Mobile gamers outnumber the console core.
9/12/2012: Zuckerberg "Facebook's Mobile opportunity is much bigger than what people think", "Everyone is now "underestimating" Facebook" (I am not ...)
10/02/2012: Windows Mobile market share continues falling
10/02/2012: 1st Apple-approved iOS game controller makes its debut
10/04/2012: Facebook Tops a Billion Users
10/09/2012: Ballmer to Microsoft shareholders: 'a fundamental shift [is] underway in our business' In his annual letter, CEO Steve Ballmer says Microsoft's future is a tight combination of hardware and software
10/12/2012: For the first time this month people searched less than last year. Our interpretation is that people now search more in context, using dedicated apps on their mobile device. This is particularly disruptive because that is the kind of search that has the most impact on commerce and advertising.
10/22/2012 Subliminal message from Zuckerberg: I would have worked at Microsoft if facebook had failed
10/25/2012 Ballmer: Microsoft has more hardware to come.
11/2/2012: Microsoft is testing its own smartphone
11/6/2012: Verizon shuts down its App Store
01/22/2013: Microsoft talks about investing 3B in Dell
02/14/2013: HP to adopt Android
Interface Builder is one of the most amazing software ever written. After 25 years (and hardly anything added to it), it is still relevant and still a GUI designer far ahead of the competion. Just let me know if you know any other piece of software that was designed 25 years ago and is still relevant today, pretty much unchanged.
When I discovered IB in 1990, I was in owe. Not only could you build incredible GUIs effortlessly (at least for the time), but IB was also an Injection Dependency Framework more than a decade ahead of Spring. It forever set the tone of my career, anchoring it in the model-driven world, building software that builts software.
That being said, I built Canappi to address a number of shortcomings which would be expected since IB was never designed to build mobile solutions and to a large extend it shows.
1. Canappi's mdsl describes the entire application in a single file: XIB files have all kinds of granularity and are generally loaded individually at different locations, directly from the code. It makes it quite dificult to have a comprehensive view of the application.
2. Canappi introduces the concept of Layout, as a set of controls, which can be reused across different views: IB does not allow you to reuse groups of controls easily, this has to be dealt in code, not at the view definition time.
3. Canappi offers standard actions (call a number, send an email, navigate to a view, present/dismiss a view...): IB doesn't have any notion of standard actions, in particular navigation actions, so you have to go back in code to implement things that could be easily dealt with at the model level, in the GUI definition
4. Canappi has introduced the concept of stylesheets: IB does not have a simple way to reuse a set of properties across the definition of several controls (TextField, Label, Button...)
5. Canappi's programming model include Web API definitions which can be bound to layout and actions: How many mobile apps need to talk to some kind of Web API? Unfortunately IB, which was build 25 years ago, knows nothing about them. With Canappi you can create a client view of a Web API (Connection), and bind operations to individual layouts, including tables and actions. Canappi generates the code to assemble the Web API request, parse the response (XML or JSON) and bind it to the controls of a View.
6. Canappi's can easily specify the layout of a table: When you drag and drop a table in a XIB file, you get, a table. You have no way to declaratively define what the table row is made of.
7. Canappi defines the whole wiring of an application, from Splash screen to Menu to every aspect of Navigation (navigation bar, navigation actions, dialogs...): Apple recently added Storyboards, but that mechanism doesn't scale very well if you application is more than a few views.
8. Canappi makes the process of designing Universal Binary easy, you can define both the iPhone and iPad layouts. Each layout is independent of each other which allows you to define different navigation schemes as well (of course the remainder of the definitions are shared between the two: connections, styles, ...): IB knows nothing about different form factors running the same application. Again, 25 years ago, this was not a common usage pattern.
9. Canappi has a much richer palette of controls: Graph (Core-Plot), Gallery, RadioButtons (yes IB doesn't have radio buttons for iOS), Button Triggered Pickers and Date Pickers, Video Player, ...
10. With Canappi you can use Interface Builder to create Android layouts. We convert Interface Builder files into mdsl, which can be used to generate both iOS and Android applications.
Canappi's mdsl is also a textual language which you can easily version, compare and merge, even create libraries of resuable application definition. IB on the other hand is a graphical tool which is ideal to position controls on a view, but far less than ideal to manage an entire application.
In fact, mdsl, Canappi's programming model, is so complete today that you can now write entire applications from it, something that is impossible to do with Interface Builder. This app was built with 700 lines of mdsl and less than 50 lines of custom code.
Data services are often an essential part of mobile solutions. It can be pretty tedious to manage a data access layer (say written in PHP) and a database schema (say MySQL).
What we noticed is that all we had to do was to create a collection for each entity and everything else would happen in mdsl. I must admit this was a nice side effect of mdsl, not necessarily something that I had designed for, I was simply exploring what you could do with MongoDB. Of course, this works well for CRUD operations since there is no data access layer per se, but still, it seems to fit lots of mobile solutions like a glove. The freedom of not having a rigid schema and the ability to add attributes and rows by hand as needed makes a big difference when you are building a solution: all the boiler plate code that keeps the client, data access layer and schema goes away. I cannot emphasize enough how easy and fast developing a connected a mobile solution becomes.
Here is a typical mdsl connection definition to a MongoDB database:
The first operation fetches the entire collection of patients (of course not very realistic). The createPatient operation POSTs a new patient to the patients’s collection. The JSON body is constructed automatically by the generated code within a “row” element as shown on the right.
Canappi’s knows readily how to create, read, update or delete these types of record.
The third operation, getPatientByEmail, implements a very simple query, using MongoDB query language and assuming the row element name is “row”. Here is what the resulting json document looks like in MongoDB, using the MongoLab console:
Here is how a join between two collections can be defined, assuming an event has a foreign key, itemid that points to an item detail document:
That's it !
No, I am not going to leave my iPhone or iPad alone for some months or scale down on using them. I am really talking about food diets. A completely different topic. As most people probably guessed by now, I am a gadget junky. I don't buy big toys (like cars), but occasionally, I like to have the latest gadget, just because it's cool. So I invested last June in a Withings scale. This is a beautiful equipment, easy to set up and completely seamless to operate. You step on the scale and it wirelessly sends you data to their server. You can display graphs and data on your favorite mobile phone or tablet.
Last November I reached 240 pounds (109 Kg). I never weighted as much before and when I saw the video of a talk I gave at l'Ecole des Mines de Nantes, I felt it was time to do something. But What ? yes eat less / better, exercise, ...
I have lost a bunch of weight twice in my life: by exercising for a whole summer and after I got maried when my wife cooked specials low cal meals. But now with two kids, jobs, and other stuff going on, nothing I could do really worked.
I even bought a fitbit to understand how much more I would have to exercise. I would not recommend anyone buying this device, this is the most expensive useless gadget I ever bought ($99). It is basically a glorified pedometer and nothing more.
So since the end of November, in about 3 months, I lost 22 pounds (10 kg), but what's most important is that the withings scale taught me how to eat and ultimately how to control my weight. So basically I dropped calories from my meals until my weight started going south. I lost all this weight without going to the gym or starving. As you can see in the graph below, when I got the scale in June, I somehow eat a bit less, but my weight crawled up until November without really understanding why. I was fighting it, but without much success.
So here is my diet (I am sure you can find yours):
I never felt hungry the whole time.
That's it, nothing else, nothing more. No need to buy a book or tapes, cook special meals, kill yourself at the gym, weight anything. Each time I did a "real meal" you can see a step in the curve. This is when we had friends at home or we went out.
Yes, and my blood pressure went down too. I am still heavy (99 Kg) so I expected it will drop more on my way to 80 Kg.
So what I learned?
Yes, my energy levels are very high, I feel really good and every morning I can't "weight" to jump on the scale.
I hope you'll find that helpful.