Featured
Articles
Latest:
. Why not promote some Programmers as much as Managers like Steve Jobs did ?
Featured:
. Holistic Project Management vs Technical Project Management: solving the problem of porting a desktop platform to mobile platforms with Fractal MVC Concept
. The hidden origin of Agile
. My personal encounter with Deming’s teaching and what I told Jeff Sutherland
. How not to let Scrum / Kanban go down the drain like 6Sigma
. Waterfall: a method that never was except by ignorance
. Carlos Ghosn on the difference of cultures between Renault and Nissan: same kind of differences as between Waterfall and Agile
. Scrum for the busy project manager or business stakeholder
. Can traditional big corporate companies really do Agile ?
. Architecture should still be at the center of Agile
. The power of Visual Thinking: combining Use Cases Diagrams with User Stories technique
Don’t miss:
Agile tools for iPhone / iPad
Note: my native language is french so forgive my english if sometimes it doesn’t sound good enough.
The advantage of “Fractal MVC” architecture: simple BDD testing without foreign framework
In a previous article, I did present an evolution of HMVC architecture pattern I called “Fractal MVC”. I mentioned briefly that, apart from MVC, it did implement reactive programming and state machine concept.
Apart from fulfilling the business and technical requirements, a major collateral consequence is Agile testing. With such implementation, the software becomes a full simulator of the application domain. You can easily record user’s action in time, replay them or invent business scenarios by chaining them in a kind of file journal with timestamp or sequence order.
You can do not only unit testing but also functional/system testing especially regression testing. You can above all do BDD style testing without the need of a specific domain language or complex framework. By using the record feature above would be similar to Excel Macro recording so that End Users could even generate / modify them easily or at least easily collaborate with developers/testers. Since the architecture implementation was meant to be portable, your test assets will also be easily portable also because it uses the same paradigm.
The first sure sign of Apple’s decline: Tim Cook is distributing dividends Steve Jobs always refused
Apple’s financial strength has never been greater. But Steve Jobs has always declined for 17 years to distribute dividends even while sitting on a pile of cash. The rationale given was that for the Company to stay ahead of competition for innovation he must be able to make small or big acquisitions at any time and of course invest in design without worrying about restricted budget – if you work in Corporate world you know what I mean. Above all he has always been suspicious with Wall Street and refused to undergo their financial pressure.
With Tim Cook, things has changed. For the first time since 1995 in Apple’s history, he announced not only dividends distribution but even a $10 billion share repurchase program.
The fact by itself is not condemnable and even understandable as Tim Cook himself doesn’t benefit from Disney’s dividends like Steve Jobs. But buyback program means lack of imagination. It may be the sure sign that Apple will be declining. This would seem like a bold claim but Edwards Deming has made a point that short term thinking is a deadly disease he directly attributed to Stock Market obligations in the United States:
“In this country, it’s all the short-term, the quarterly profit, the next 90-day appraisal. The American businessman is afraid to look beyond tomorrow because the bank and the stock market and the investors want results now.”
That doesn’t mean Deming was against profit he was rather for long term profit:
Nobody gives a hoot about profit. I mean long-term profit.
Tim Cook’s move is the proof that, unlike Steve Jobs, he’s not and will less and less be able to resist the “sharks of Wall Street”. Though Apple’s sale is still strong and even stronger, he’s just profiting from the momentum Steve Jobs had built with so many sufferings at the start when nobody did believe yet in him. Tim Cook has currently no merit because as Deming put it again:
“Any manager can do well in an expanding market.”
I takes longer to build a company that it takes to destroy it. Look at any stock chart growth. Even when it is steady the decline will be even sharper – due to some kind of gravitation law. In fact some financial analysts are already starting to worry by comparing Apple’s stock to Cisco’s tock in the 1995-2000 era. Technical analysis alone doesn’t make a sure prediction but combined with fundamental change it can be a good indicator. Tim Cook’s decision is a sign of such fundamentals. Not a good one – no financial analysts have yet commented on this but of course they will after the facts in a few years when things are already too late I guess.
Why not promote some Programmers as much as Managers like Steve Jobs did ?
Meritocracy is a sound principle and this article is not about preaching equality at all. Because everybody knows or should know about the Peter Principle:
“employees tend to rise to their level of incompetence.”
Is is the fault of the employees ? No it’s the fault of the System (organization) which promotes “Management Illness”: many operationals / doers who love their current job seem to admit they have to give it up for Management – read for example the case of Tim Delaney and David Abbott – to have better salary and/or recognition. In fact it may be more about recognition than even money (watch Daniel Pink’s TED conference below on the surprising science of motivation) but as salary is a standard measure of recognition in our common society people who even looks for only that will ask for a better paid job.
Steve Jobs never mentioned Peter Principle as far as I know but he did realize that Management shoudn’t be an end. Everybody knows that Apple is the only big company where Designers are directly under the CEO responsability. Less knows that every year Steve Jobs did invite 100 persons at a secret conference and some Programmers were selected to be present whereas even their Managers weren’t.
Because of this obsession on becoming a Manager, many politics in an organization occur because of people trying to escalate the Corporate ladder instead of concentrating and contributing positively on the projects they’re working on – notwithstanding manipulators, often favored in that kind of system, who are counter-productive parasits on a project. Lean Management has been invented to eliminate waste, so why not get rid off that obvious source of waste ?
Of course not all programmers are the same. According to Facebook CEO and also Steve Jobs one programmer could be 100 times better than the average one. Only really best programmers should be promoted or recognized as such. This will create better motivation for others – instead of widespread frustrations of being just interchangeable commodities – to try to invest themselves at improving their skills knowing it can be rewarding.
People talks about “secret sauce” of Steve Jobs trying to emulate him. Problem is that there is no real secret but just common sense organization doesn’t want to apply because the organization rules are made by the same who have vested interest not to change it. Only investors could – and maybe one day they will realize they have the power to change things on that plan (everybody can be an investor by just buying a few stocks). At least on smaller scale organizations, some did apply it like Tracy Dolgin.
Holistic Project Management vs Technical Project Management
Solving the problem of porting a Desktop Platform to Mobile Platforms with Fractal MVC Concept the Agile Way
I read this interesting interview of Flipboard CEO on BusinessInsider about the first engineer he recruited:
I hired this guy Evan Doll from Apple who was on the original iPhone team. He and I started working together and it was pretty clear to me when I met him, that he was going to be more than an engineer to work with, that he’d be the kind of person I could actually start a company with. He has the judgment, the sensibility and the holistic thinking that’s needed to be a founder, not just an engineer.
As an engineer myself – not in software but in industry and quality originally – I do always tackle any problem with a broader view than just a pure technical one. For example, I’ve just worked on a project for a financial credit subsidiary of an automobile company where our developers have to port about 50 totally independant no-mvc flash applications to mobile platforms (they should have been factorized but historically they weren’t when I arrived on the project – indeed the new architecture was also to ease future unification). The specifities are that the majority of components have to be crafted with custom graphical design per brand (2 partners brands actually). Also there were a lot of business rules that create an overwhelming number of dependencies between the different components – increasing the complexity manyfolds. Last but not least the application is meant to be used in the context of an internet mashup by 2 partners brands and we totally ignored at the time of decision what platforms these brands would be adopting – hence the new implementation should be portable also to Objective C / iPhone SDK, Java / Android SDK, Silverlight and of course Javascript / HTML5. So how to port all these components automatically in very short time to mobile and maintain them in the future with the same team ?
Well there is Adobe Air (and Adobe JSFalcon converter but which is not even ready today). But do you remember Apple did forbid Flash CS5 embedding tools for native apps some time ago ? Though this restriction has been alleviated it still doesn’t solve the problem that your application must also be accessible on the iPad in html5. So the idea of Fractal. This concept has a huge broad range of applications from 3D graphics to Stock Market modelisation. In fact I was originally attracted to Mandelbrot’s theory in that field. I thought that this concept could be applied to Software enginiering. In truth I had already that idea in mind since ten years (I first wrote a paper untitled “Unified Modeling Object” that I unfortunately lost) and start applying it already in past projects with Code Generation and Naked Object Architecture for a previous client banking system project. This time again, this concept was usable.
After all Componentization is about recursively embedding sub-components so somehow this idea should be natural. I start looking at what exist and stumbled upon this fractal framework which was unfortunately more targeted at distributed components architecture than to visual components architecture. I looked of course also at current more well known MVC frameworks like pureMVC but they all possess only “one dimension”. So an “n-dimensional” MVC was actually what I was looking for and indeed Jawaworld did publish an article untitled “HMVC: The layered pattern for developing strong client tiers”.
Nevertheless the implementation described wasn’t “Fractal” enough for me so I combined the idea of HMVC with the idea of Reactive Programming used in the Microsoft Rx Framework though there was no need to go as far as making everything reactive just the setter and getter would be enough applying the idea of SPOC (Single Point of Control). Each SPOC though not an object will act as the subject of an Observer Pattern. Then the design principle is simple: to bootstrap the system, first build an infrastructure of message pipelines, send the messages, and like for an Egyptian pyramid, the system builds up in cascade passing through all the SPOCs for business rules, and synchronize the visual GUI with all the super model and submodels magically. It also important and helpfull to understand that each entity was like a state-machine at every level.
When I did submit that kind of idea to developers, it seems simple enough in principle, but when the implementation phase came, they were stuck in front of a blank page. Because how can only a few simple rules build up a whole complex application ? I wasn’t astonished because the paradox between simplicity and complexity is always challenging. For example many developers in general have difficulties to understand how Class Interface which are completely empty could be as usefull as a plain full class. The solution to get out of procrastination is dead simple: just plan some agile iterations of course. Start with a simple component like a slider. Add some rules. Then add a parent component, then build the infrastructure for the message pipelines – if you forget to do so the messages cannot be received and the system cannot bootstrap so obviously so you’ll obviously ask why, find the reason and fix this. That’s how you can build an architecture the Agile way without any framework just using a few guidelines (we built a framework only for our public API that were exposing some query and state methods but none for the internal components).
Above all the interest is the systematic and simplicity of the code at every level of components which insure its portability and even automation through code generator that can be crafted using basic templating engine – Visual Studio T4, StringTemplate, … but even a good search & replace tool may be just fine and the whole structure of the first project can serve as kind of scaffolding template for the next ones. Crafting a full blown framework very much depends on the specifities of a platform, requires higher competencies (Use of Reflection maybe even undocumented methods) and development time which was much lacking. Flash developers are web programmers not Phd system engineers. Above all an Architecture is more about finding the Invariance of a System than building a library container per se – though this is very frequent from software editors because it is their core business – whereas the client here is not such type of company – and the the rationale is it would be counterproductive, risky and lengthy (multi-years men project just for the core system instead of a few months).
Jim Coplien Why Architecture is needed even in Agile?
I stumbled today upon an excellent audio interview of Jim Coplien who pinpoints the misunderstanding of common Agile practice. He urges to go back to the Root Principles of Japenese Lean. I cannot agree more since I wrote “The hidden origin of Agile”. He also warns about the dangerous belief that Architecture Design is no more necessary and that I agree upon also. I even think that Agile is dangerous to start if technical debt is too high and that Architecture should still be at the center of Agile.
How your project may fail even more faster with Agile than with Waterfall
If you have read a few of my posts like Waterfall a method that never was except by ignorance, you have no doubt I am a strong proponent of Agile rather than Waterfall. Nevertheless, if your organization (manager, purchasing department,…), your business and developpement teams and your subcontractors are not adequately prepared for Agile, your project may go down the drain even faster.
A typical scenario is this: the business people don’t know how to formalize a business requirements and may pretext they don’t have time to do so. IT Manager read 01 Informatique (a famous Enterprise IT Magazine) and learned that Agile will be the great savior: no more late and out of budget project, happy business people because they don’t need to write everything down. Except that it can become worse.
In corporate organization, business users who are stakeholders may not be end-users who will actually use the application. They may decide without consulting the operational people and they are not interested in the real usability of the software only on superficial graphical design. They may not want to commit the time necessary in Agile methodology and so in the end the developers have no real specifications.
In that case Waterfall is preferable because you have at least some documents instead of nothing from Business. Agile can only be started in corporate company when there is a strong momentum accross all teams to really be able to succeed.
My personal encounter with Deming’s teaching and what I told Jeff Sutherland
I’ve been a project manager in software development in France for about 15 years now. But I started in the past in statistical quality engineering field from the school of Deming. I had the chance to invite for a conference series – when I was still an engineering student – a very close friend of Edwards Deming in person – Mr Jean Marie Gogue who also translated in French Deming’s book Out of the Crisis – and what he told me about the history of Japanese Quality and Deming astonished me as my professors in management never taught me that. In fact I did not really understand his message because it was so contrary to the mainstream teaching I received at that time.
For example, I did create myself for his conference what I thought was a smart poster illustrating the “seven zero defects” where I did put the slogan “0+0+…+0=Quality”. I felt ashamed and a bit angry when he stared at the picture and frankly said: “I don’t like it”. Later he was kind enough though to invite me at his office and explain the reason why (paraphrasing what he told me): “the story behind the zero defects is that Phil Crosby who was my colleague at AT&T had difficulty to understand Deming’s statistical theory so he needed to invent some pictures to illustrate it. Unfortunately it has become a slogan that has been misunderstood by the people”.
Years after years I discovered what was this misunderstanding: people did use statistics wrongly for ranking and post-control instead of hypothesis tools to put process under control and then improve the variation of it. Above all people did not at all consider what was the most important in Deming’s philosophy: the scientific spirit of induction and deduction behind his PDCA cycle (iterative process) with his theory of profound knowledge about the system improvement as a whole and not as independant parts because optimizing parts separately may not have any benefits and even such negative effects as destroying the company year after year.
What the friend of Deming also told me is that Deming was very upset to have succeeded in Japan but not in America or in US because in Japan after World War II, the General Mac Arthur replaced the CEOs by young engineers and ordered them to follow the teaching of Deming so that the knowledge did come from the top and had the huge impact we all know on Japanese Industry Quality in the end – because in the 1960s their products still have bad reputation.
So when I did follow a 2-day course of Jeff Sutherland, that’s the first and only thing I wanted to tell him (I paid from my own pocket a few thousand Euros just to be able to just do that – because I wasn’t really interested by certification or Scrum I already knew 
): “Jeff the pity with Agile is that it doesn’t really impact the Top Management of the whole enterprise. Deming failed in America contrary to Japan because of that. You should try to also target the top CTOs and CEOs instead of software technicians with your seminars” – I thought his personal reputation has grown enough for him to be credible. Well I don’t know if he did remember what I said but I’m happy that he seems to just start targeting them as he tells in this interview on Forbes. I’m also very gratefull that he honored Deming at the end of the video: Edwards Deming was an humble man and he should not be forgotten.
Iteration should not be reduced to Scrum time-boxed cycle
There seems to be some rebellions against Scrum time-boxed iterations like on leansoftwareengineering. Some have been willing to announce her death sentence. This latter title was clearly meant to be controversial but as every controversy if you read the arguments, they all seem reasonable. So here’s my viewpoint which I think is quite different from most opinions that have been asked on AgileScout.
Let’s remark that in general most controversies originate from semantics and this one doesn’t escape the category. Because the critics here is about time-boxed cycle named iteration in Scrum parliance and as Scrum has widespread to become dominant in Agile methodology, iteration tends to have reduced to a narrowed time cycle definition. I think these authors make a great service to Agile by pinpointing the danger of time-boxed cycle because this reminds of Taylorism.
But my viewpoint is that instead of getting rid off iteration per-se, one should restore the original meaning of iteration by going back to the hidden origin of Agile. As I said, Agile did inspire from Lean which tried to restore lost Deming‘s principles in Quality. For Deming, iteration is a fundamental tool of continuous improvement principle, which he reifies in his Deming Wheel or PDCA cycle. This cycle or circle or rather spiral is less about time or cadence but about the 4 sequences of Plan-Do-Check-Act (Correct) which should be repeated over and over again which constitutes the operational definition (also a key Deming concept) behind continuous improvement. This PDCA comes itself from the scientific process composed of Induction and Deduction phases. The reason Deming and Shewhart did invent that Wheel is Visual Thinking to make the mass understand abstract concepts in factories.
So if people get rid off Iteration even if they were meaning cadence, the risk is that there would be no name left for the real concept of Iteration. So instead of announcing the death of Iteration, just rather kill time-boxed cycle alone but please restore the term iteration to her original meaning.
Scrum for the busy project manager or business stakeholder
If you have no idea of what Scrum is and you’re too busy to follow a seminar on the subject, this is a quick summary for you.
The essence of Scrum is time-boxed iterations officially called sprints. It may be 2 weeks-length but it’s up to you depending on your type of project and organization. At the end of a sprint a workable demo should be delivered during a Review meeting where business users will be able to test and give feedback. This demo is not a throwable piece of software but a part of the final software with partial functionalities – concept of incremental and iterative development or IID.
In the spirit of Agile, Interaction between people are keys so that Business People and Development Team should be in constant involvement with each other. There is no product or project manager but a product owner and a scrummaster (in corporate organization he may be a former project manager or a lead developer). The product owner will drive the business requirements through a list of desired features called user stories which will be accumulated in a product backlog. The scrummaster will then be able to pick up some stories towards the sprint backlog during a sprint planning meeting – which occurs at the beginning of each sprint. The selection of the stories will depend on the priorities given by the product owner. Team members will then list the tasks derived from the sprint stories and put them on a task board. The taskboard is divided into vertical lanes like “to do”, “in progress”, “test”, “done” (or one could use Deming’s PDCA – plan do check act/correct).
The motto of Scrum – in fact of Agile – is transparency and courage so everyday, team members will attend a daily standup meeting (about 15 minutes) where each one will assess the progress of the sprint (expose the status of his tasks, the impediments encountered and his tasks plan for the day by updating the task board,…) and of the whole scrum implementation itself through retrospectives. Scrum also prepare a burndown chart which supposedly reflects the number of work done substracted from the whole number of works necessary for all iterations to make a release – so to speak release planning which is the theorical base for comparison to actual. Numbers are counted in relative points or in periods – named story points. Each point is relative from team to team and take as reference a simple task (for example creating a dialog box). These points are estimated during the sprint planning meeting by all the team members often using a technique called poker planning.
This is as quick summary as possible but of course following a course is best.
Waterfall: a method that never was except by ignorance
Waterfall “method” is said to have been invented by Winston W. Royce. Royce is considered as one of the leaders in software development in the second half of the 20th century. Let’s hear what he said about Waterfall in his 1970′s paper (though he didn’t give any name to this “method” at that time):
I believe in this concept, but the implementation described above is risky and invites failure.
He clearly discourages to use this model and, according to Craig Larman, his son confirmed:
He was always a proponent of iterative, incremental, evolutionary development. His paper described the waterfall as the simplest description, but that it would not work for all but the most straightforward projects. The rest of his paper describes [iterative practices] within the context of the 60s/70s government contracting models (a serious set of constraints).
Beyond the irony that Royce wasn’t at all the father of Waterfall but quite the contrary a proponent of iterative process, how did it come that Waterfall did reign for 40 years and even now in corporate companies it is still considered a healthly process ?
Well, in 1985 DOD-STD-2167 MILITARY STANDARD: DEFENSE SYSTEM SOFTWARE DEVELOPMENT requires the use of Waterfall Model. Though this emphasis on Waterfall was removed in MIL-STD-498 and IID (Iterative and Incremental Development) was promoted in 1994, other world governments standards didn’t follow. In Engineering school Waterfall is still taught as well as in Business School.
According to Craig Larman this happened because the author of DOD-STD-2167 was ignorant of IID and confessed his regret that in hindsight, he would have made a strong IID recommendation, rather than what was in 2167.
This story just reflects what’s happening in all corporate organizations: a few people who are ignorant of real best practices wrote governance laws that in truth promotes unrealistic, costfull and bad practices and as they don’t follow any quality improvement themselves by listening to the users of their norm, things can’t change. This is absolutly scary if it wasn’t also funny. Also how many hundred of Billions have been wasted for such a long time ? Nobody will ever be able to quantify but that’s an illustration of Deming saying that non visible figures also count !
Anywhow anybody should spread the story where more details can be found in Craig Larman’s book:
