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>
I define a problem formally as a non existing transition between two known states [1], 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 [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:
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):
[3] Living Social Business Strategy mapped using the same conceptual framework (Source: B = mc2)
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.
07/25/12
Mobile App Monetization
David Barnard wrote a really interesting post on the recent acquisition of Sparrow. This is a must read for any mobile developer expecting to make a living from their craft. This could actually very well be the best article written on the topic.
But I want to warn people against his conclusion. I think there are two elements of his rationale that are flawed. He wrote back in 2009:
unrealistic pricing expectations [...] may haunt the entire mobile software industry for years to come
And added today:
In hindsight, I think “haunt” was the wrong word to use. Though it wouldn’t fit quite as well semantically, or be quite as provocative, I think the right word to use there is “change”.
The reality is that Apple successfully delivered a monetization platform, this is actually one of the most fundamental change introduced by mobility (with location). Not so much because developers can -now- potentially be free from the -bait- model the Web introduced where the end-user "is-the-product", but because now commerce can be delivered in a fundamentally different way. An app is just an agent of commerce not the object of commerce
The Web never ever changed how commerce was done. e-Commerce was commerce and is still commerce 20 years later, you still take this bit of plastic out of your wallet, and you still establish a one to many relationship between yourself and a bunch of people. Even in other areas such as outsourcing, the Web didn't change much, call centers existed before the Web, they simply moved. The Web just abstracted (a bit) location, but for all intend and purposes the Web didn't change a single thing to the way commerce was done. It might have gave you the illusion, that's all.
What The Platform is changing fundamentally is that it introduces a mediator in the commerce relationship, a One-to-One-to-Many relationship, actually it is even more complex than that, it introduces a One(end-user)-to-Many(apps)-to-One(platform)-to-Many(merchants, service providers). It does that in a relatively secure and private way allowing financial transactions to flow between all these actors.
Claiming that you can't make a living because a single business model (selling apps on the app store) doesn't seem to bring in enough income is at best short sighted. I can come up with at least 10 transaction models (exclusing ads which transformed the web into a zoo) that will help developers and service providers monetize their relationship to end-users.
Just this morning I stumbled upon this eBook that the French newspaper Le Monde just published. It was written on iBook Author, one of the most amazing "app" I have seen in a long time. And all the sudden everything became clear, this was the business model the press was waiting for: news has become a commodity, nobody wants to pay for news. Social network have forever disrupted the relationship between newspapers and their readers. But ... at roughly $5, lots of people might pay for the analysis behind the news, the broad perspective that the journalists can provide because they follow astutely "the news". And yes, in case you have not noticed, in a fairly incredible turn of events, turning the entire model of the press on its head, the "news" becomes the ad that would lead to customers buying the eBook. What better ad, than a piece of news that will drive people wanting to know more, wanting to understand deeper perspectives well beyond the news?
The second flaw in David's rational is the "one-size-fits-all" mentality of app developers. This is a major flaw, again inherited from a very old age, when you could not address a billion potential customers. This is what "The Platform" changes, unlike the Web, which at best allowed one person to buy stuff and services from a remote places, the platform turns the entire commerce model on its head. It allows anyone including David to sell into a one+ billion user market. Do you really think that "one app" can appeal to 1B users? Angry Birds, anyone? Isn't it time to rethink what software is? Don't you think that a) if you are lucky, one app would only resonate with a small subset of this billion users and b) if you are not, you may never find your market, when in reality a different set of features organized in a family of apps could have found many "puddles" of 10-20 million users? Take any of David's apps, don't you see how they could be organized into a family of apps that could appeal to many different market segments, geographies, ... even price could be different. Some users might be paying $20 for a premium app, other would never pay more than $.99 for a couple of features, but maybe that's a 100 million puddle.
For the last 20 years our economy has been trained to standardize products and to perform binary commerce transactions. I don't know the future, all I know is that people who will not think out of the box page and people who will not try to understand the tectonic shift introduced by the Platform will come to the wrong conclusions. In essence, the only thing these people are telling us, is that BAU (Business As Usual) is dead because it does not work on the platform.
Of my entire career, nothing has been more dramatic and transformational than when Steve Jobs returned to Apple in 1997 and shelved NeXTStep. All my dreams, all I had worked for, for 10 years, were shelved as well. By then, companies like GM, Hughes, Samsung, NTT, Siemens, EADS (Aéropsatiale back then), Essilor, lots of research labs in Europe, ... were using my software doing great things with it and somehow, this was shattered in one instant. Believe me, when people complained they could not upgrade their Lumia 900 to Windows 8, they are not even 100 miles close to the pain you get when you see a full decade's worth of work go away as your technology platform vanishes before your eyes. To a certain degree I think we have all lived this kind of event, not as instant and comprehensive as the NeXTStep one. Even Flash gave a 5 year warning to its developers.
With that in mind, I was amused to see this Mobile Development Platforms Gartner Quadrant this morning. A friend of mine asked me what did I think of it? What is a sensible no-bs lasting mobile strategy in 2012? I didn't see the Web Platform Magic Quadrant CIRCA 1995, but I bet it was not much different. Tiny (NeXTStep-based) WebObjects was the leader then... how many iterations have we been through? who could have predicted the rise of PHP? where are we now? All we know is hype always got it wrong, despite all the might of a Gartner or an IBM or Microsoft, completely wrong. "What works" wins. Always. So here is my answer:
1. Create your picture of the device market
We are at the last stop before this market is completely locked in by Apple and Google. I wrote that piece a couple months ago explaining that unless Microsoft somehow associates itself strongly with Facebook, Nokia and HP and adopts a vertical strategy, there will be no Microsoft in the mobile space moving forward. Today we know for sure the device market will be at most a three platform game and, after watching Google I/O's Keynote, my bet is that it will be just two platforms. Anyone who is trying to convince you otherwise simply doesn't understand that a device that runs an app can no longer exist without a platform behind it. If Sony, RIM or even Amazon do not have a sustainable platform behind their devices, nobody will buy them. It's funny how people can't grasp the "form factor" of software: they see a device, they think this little thing is autonomous, doesn't rely on something other than a voice and data connection, they don't see the extend of the software component behind. If they somehow could visualize some of their systems with a physical representation, I bet our industry would look much different. For instance this is a picture of the Nokia Lumis 900 after Microsoft's annoucement last week and here is a "Kindle" for instance (albeit not as pretty, I mean the Kindle is not as pretty as this public bench):
2. Understand that writing software for mobile devices is unlike like writing software for desktop
I would recommend a couple of presentations:
a) 6 Design Rules to Design Amazing Apps
b) Building Mobile Applications That Rock
I would also recommend you understand where you fit and how you plan to use the mobile ecosystem. Here is a map that can help you:
3. Native vs Web?
Except for the people that make a living off Web technologies or the ones that are emotionally attached to the Web as a platform, everybody will tell you that HTML5 is not there yet and most likely will take at least a couple of years before it can catch up with native technologies, if ever. Just ask yourself how many Web apps do you actually use on your own smartphone? zero? Why don't you also ask, of all the native apps that you use, which one would be better as a "Web app"? zero? Users choose the best UX, period, technology is the least important factor in their choice. I mean come on, after nearly 20 years of evolution who can tell me that even on the desktop there is a Web app they would still use if they had a native choice? Everything that the Web was not, Apple baked it in its platform and won. Maybe the industry could stop for a second and ask why? If you still don't believe me, please watch this presentation. Even Facebook finally gave up ...
Not only Mobile Web frameworks don't work well in all the devices browser (contrary what the vendors say...), but you'll still have to deal with pixel level precision across multiple device form factors, they don't do that, not even close. Do yourself a favor, try building a small sample app (3-5 views with an API call) in iOS, Android and jQuery mobile, and try to run it on 5 common devices and let's talk again. Just for fun, just embed a call to a mobile Web page within one of your WebView and compare the user experience with the corresponding native view. Yes, as Google pointed out in its keynote the human eye can detect up to 10 ms delays. Even a ping can't be done in 10 ms.
If you want to take advantage of all the latest device capabilities do you think native or Web technologies will give you the best access? If you want to save bandwidth, power and deliver the best user experience, which app will do that? Native or Web?
Do you have an Android device? What do you think of the Google Weather App? yes, when you ask for the forecast and you are redirected to a "mobile-optimized" web page that displays the weather forecast in your city. Do you think you want your users to go throught the same kind of experience? Yeah, I guess you get my point.
Don't be fooled by Web developers who see the train coming (or going) and they are either going to be steamrolled by it, (or simply stay on the Web platform, so to speak).
So, with 2 platforms to support, it is actually fairly easy to build a mobile team that will be proficient in both. Beware of people scaring you with the wrong problems to buy their tools. The only problem you have, the only question you should answer is how do I deliver the best user experience in the context in which the app is used for the devices that my end users have. Everything else is a waste of time, because we are now in an End-User driven market, geeks no longer have the luxury to chose what is convenient to them. They hate it, this is the first time in history they lost control of their technology choices, but they are going to have to learn to live with it if they want to tap the 1+ billion user smartphone market. That's actually very refreshing. End-users expect certain patterns and behaviors, these patterns and behaviors are all native. One of them is actually quite interesting: End-Users expect to spend money to buy native apps...
4. Middleware
You would think by now that most companies will have developped some kind of allergy to proprietary/closed middleware platforms (or at least an immunisation mechanism). It is already bad enough to be locked in Apple and Google, imagine being locked in a much smaller vendor who can disappear, change direction or be acquired any minute. Yep, that's the value proposition of companies like Rhomobile (now SAP) or Antenna: support all the platforms you don't need while you get locked in ours. Even IBM would have never thought of this ... wait actually they did. They bought WorkLight for 70 M.
Why don't you ask them how fast they are going to be following evolutions of Apple and Android SDKs and how low the common denominator in supporting every platform is going to be?
5. Keep it Simple
In the light of this context:
- Rapidly evolving technologies and devices
- Quasi certain dominance of 2, likely, or 3 vendors at most
- UX being the prime factor of the success of an app
- Pixel level precision GUIs
- The Platform beneath
- Subpar Web technologies
If Instagram can teach us something (other than printing money) is that Content is now produced, delivered and consumed in a completely different way: in context. The browser is dead, long live HTTP. Everything is on the table to be reinvented.
My recommendation is keep your strategy as simple as possible: write your apps for iOS and Android. This is not the end of the world, it is relatively easy to hire a small team of polyglot developers. You don't need no middleware for that. Before you know it you would have spent millions of dollars for capturing just a few % of the device market or supposedly empower your developers to write apps in ... two platforms. Who in their right mind would spend that kind of money? Where is the business case? Just buy an iPhone or an Android phone for your employees who use any other device. That will be much cheaper than any middleware or developing for additional platforms.
Gartner will always be Gartner, they make lots of money selling these Magic Quadrants to both ... the vendors and their "customers". So you have to decide whether you want to be scared by that picture or leap-frog it with a Simple (but far from simplistic) Mobile Strategy. Your call ...
Post Scriptum: Mobile Web Sites
Yes, mobile Web sites are not going away. And HTML5 is a good fit for them. But you have to think in terms of form factors: understand that "search" has become an "app", a family of apps. You search in context, Yelp, UrbanSpoon, Fandango... on a mobile device, you rarely search out of the blue or research some information for your homework or paper. You search for a purpose and there is a search app for every purpose you can think of. Search might even be considered just a feature, not even a family of apps. So think of your mobile Web site as being a way to publish information to a small search app that people use now and then and that app is called Google. Again, think in terms of form factors. The Web form factor in a mobile world is this tiny island of HTML rounded up by a -plain vanilla- contexless search app. So all you really need is a couple of "Web" pages so people can find you if they care to look. Make sure you provide a link to your native apps on these pages. That's all your users care about. The Web is emphatically tethered. Make no mistake about ot.
