The Age of Design

In past few years climate and environment concerns have taken centre stage. Though climate debate has many connotations ranging from political to economical it is widely accepted that society has to introspect and change its course in how it produces and consumes. Industrial design will undergo a change. Not only products need to provide " experience" to its users, which anyway is essence of good design, but there will be increased emphasis on how waste is eliminated. For long, designers have overlooked the waste that is produced in process of creating a product or by product. But not in future. So, to paint a happy picture, our houses will get designed akin to a tree which generates its own energy from sun and leaves no trace of waste. Waste has to be eliminated or reduced by design and it is fundamental element of what is being called as Green design. This falls in realm of industrial design, but what about software design! Shouldn’t aim of software design also be to create a compelling experience to its users and eliminate waste?

Charles Eames defines design as "a plan for arranging elements in such a way as best to accomplish a particular purpose". In industrial design, product designers combine skills spanning disciplines of art, science and technology to create tangible goods with focus on aesthetics and usability of end product. In software design, and especially when it comes to design of enterprise software, emphasize is more on how internals of software will be built than how it will be used by end users to achieve their goals. Sample a typical software development process – a need is identified by a department or a group and requirements are captured by business analysts. These requirements are then passed to development team to begin development tasks. The programmers build the application in accordance with style guide that usually dictate elements such as font size, colors, and includes other user interface specifications. In many cases, the application is built with a skeletal interface which is then skinned by a designer to give it required visual appeal as per organization standards . Application is then tested and rolled out to end users. Results could vary from a system which doesn’t meet the real goals of users to frustration emanating from poor usability. This sounds like a sweeping statement in absence of data to back it up but one can safely rely on general perception that enterprise software has. Poor usability causes users to waste time performing routine tasks and lead to a lot of frustration and poor productivity. A definite waste. An aspects which is fundamental to industrial design is visualization. Almost every physical good which is produced is visualized through models before it is actually built. Cars, planes, cell phones all these are visualized during design stage. So a product can actually be "seen" before it is built. In software design, though there has always been practice of prototyping user interface , it is mostly relegated to low fidelity wireframes focusing on information architecture. Except for software built in agile fashion, generally it is too late in day when system becomes "visible" to know what features are really useful and required and what are not. And changes become costlier leading to waste of human effort and money. A definite waste. It is easy to argue that Software design has to encompass broader meaning of designing as a product from user’s point of view and also employ prototyping techniques to visualize before building.

We are in age of design and we see it all around us. These are times of iPods,Web2.0, DIY applications which have hooked users through compelling user experience and have transformed society in their own way. In life that is becoming increasingly busy, where attention spans are decreasing, user behavior is complex, and a marketplace which is dynamic and fickle, organizations that understand essence of design and adopt a user centered approach for software design will do better than those which don’t.

(First posted in Capping IT Off)

Does Agile mean no Processes and no Governance?

There are two generally held perceptions about agile. One, that agile is a kind of anarchist model with no processes, and second, that agile means no governance. Let’s look at the first perception that agile means no processes. We can understand how agile looks at need of processes by applying a well known principle called Occam's razor which states that ” one should not increase, beyond what is necessary, the number of entities required to explain anything”. The principle helps us to remove those concepts, variables or constructs that are not needed to explain a phenomenon. By doing this, it becomes easier to create a model which resembles reality much better and redundancy and inconsistency is removed. In essence, Occam's razor stipulates that when multiple theories are available to explain a problem, the simplest one is preferred. Nature likes simplicity. Ocaam's razor when applied to project management methods would imply that a Project should have only those processes which are required and not more. This is exactly what agile paradigm means with its use of low ceremony, just enough processes. Agile teams chose processes which are most relevant for them to meet their goals in their context. It means you do not pick set of pre-defined, rigid processes in a bunch and deploy them on a project. A process is good as long as it adds value to project; or it should be discarded or amended. So, why is to so hard to agree with this!

It is possibly due to the fact that traditional management methods have relied heavily on process standardization and execution efficiency. But it has not helped achieve predictability of results which is clear from number of IT project failures. Today's business scenario is vastly different with constant change and dynamic markets. Project teams like Organizations need to adapt quickly. Traditional methods, which are based on "execution as efficiency”, find this hard to achieve because they inherently oppose changes in system. In a Harvard business review paper published in 2008, Professor Amy Edmondson identifies a different approach to execution, called "execution as learning" which looks uncannily similar to agile thinking of software development. She calls execution as learning “a radically different organizational mind-set, one that focuses not so much on making sure a process is carried out as on helping it evolve". Agile practitioners would easily relate to her thoughts and “execution as learning” looks very similar to agile manifesto.

Second perception about agile is that there is no or very little Governance in agile methods. But the fact is that agile makes governance more effective as it puts onus on participation of all stakeholders in project. Traditional command and control governance models usually end up creating bureaucratic hurdles and illusion of control. Agile governance model on the other hand is about enabling the team and facilitating an environment where team can meet its objective without avoidable hindrances. Whole team principle is about shared vision and goals and that there are no finger pointing and putting the blame when and if things go wrong. Should project sponsor remain a distant illusive figure or rather become part of the team! Perception of agile being low on governance perhaps comes from principle of "self-organizing teams". Scott Ambler explains this principle when he says that "self organizing doesn’t mean that you are out of control and doing your own thing. It means that team members are themselves deciding how to meet the goals. But the goals they have to meet, the resources used and timeframe, are governed by organization". Agile governance he says is about keeping the baby and throwing the bathwater. And that might well summarize processes and governance perspective in agile.

(First appeared on Capgemini technology blog )

Going Agile - Just another collection of good practices.

Agile practices for creating software within enterprises have been gaining ground in recent times. Even though shift is not tectonic but subtle, it is important nonetheless. One of main reasons for this has been that many big enterprises have realized that traditional methods have failed them at times. I have seen quite a few big enterprises spending millions of dollars on projects just to realize that projects very often overrun cost and don’t give them operational systems as they would have envisioned.

Do it Small and Detect early: Software projects fail for various reasons and going agile is not the panacea and it doesn't guarantee success either. But what Agile does is that, it reduces chances of a costly failure as progress of project is known to all stakeholders and an early decision about termination of project or change of course can be taken. A constant progress monitoring of project, continuous build and test, small iterations,sprints etc lead to early detection of problems if any. In this regard Agile is akin to RUP like iterative approach and breaking big into many smalls and doing continous health checks on them.

Focuss On People: But most importantly, What Agile also does is that it brings focus on people and project teams and put them in control. Process boundaries are lowered so there are no processes to cover for failures later. Fetish for processes is diluted so that team doesn’t drown beneath cumbersome and often stifling processes. People are the key ingredient for projects to either succeed or failure. Agile project teams are empowered to think and adapt as needed for success of project. Since teams are in control of project, they can not turn around and blame someone else or some process later for failure. Agile makes team members more visible and accountable. In principle, Agile just states a truth which many would want to ignore for sake of industrialization of software that People are most important element of code assembly line and heroes need not be discouraged.

One caution which enterprises adopting Agile has to follow is that they need to make sure that all pre-conditions for agile to work are met. Agile need some cultural changes and mindset adjustments. Agile teams are built around trust and openness to change. Most Agile teams are cross functional with Business and IT skills working in very close cooperation. Enterprises outsourcing their Software needs to vendors and using agile should keep in mind few things :

1.) Put key personnel in charge: Key Business and IT people should be put in charge of project (well, shouldn't that be true anyway ;)).

2.) Accountable Product Owners: Product owners should be people in your organization who can answer questions. Buck should stop with them. Very often cause of project failure is due to volatile requirements or difficulty in nailing them down properly and on time. Especially if organization is big and diverse, getting access to business people who can provide answers is difficult. This should be changed with empowered product owners being part of project team and not just as outsiders.

3.) Build Prescriptive Processes: Agile doesn’t mean no process. It doesn’t mean guerilla programming either. Agile means adapting quickly to changed scenario or context. Instead of a frozen, rigid, descriptive Process, a prescriptive process or Meta-process can be created so that agile teams are operating within a known process framework but with desired leeway to improvise and maneuver.

5.) Model for Offshore Agile: As is the norm these days, if agile team is distributed across locations, put some thought on how multi location latency can be managed. Decide if you would need proxy product owners in remote teams or how cross pollination would be done to maintain one team spirit of Agile. Remember that Agile can be adapted to your specific needs and constraints. Purists would say that distributed teams are not pure agile teams, but real spirit of Agile is adaptability and not maintaining purity.

6.) Agile doesn't mean cheap: Agile doesn’t mean less cost of doing software. In fact it can mean more build cost. Successful agile projects would create value in terms of reducing hidden costs which are usually accrued in traditional methods of tight control and change aversion.

7.) Fixed price versus TnM Get over fixed price mindset. Fixed cost projects don’t reduce your risks anyway. They only delay the costs by converting them into Hidden costs (Change requests, maintenance) .

8.) Not for all conditions: Agile might not be suited for all scenarios. In many cases, traditional methods of tighter control, elaborate requirements in beginning and managing change are required. There is never fit all solution.

Ultimately, Agile is just a collection of good development practices which puts value and emphasize on certain aspects of software engineering. Keep overzealous agile evangelists and those who think it is passing fad at equidistance.