Friday, June 5, 2015

Me@AgileIndia2015


Agile-India is Asia’s largest & premier international conference on Agile and Lean Software Development methods. AgileIndia 2015 conference held between 25th and 28th of March, focused on scaling agile & lean methods in Large Enterprises.  This year the conference attracted 850+ delegates from 43 different countries. The conference is organized by Agile Software Community of India (ASCI), a registered society founded by a group of agile enthusiasts and practitioners from companies that practice Agile Software Development methodologies.  I was part of Organizing committee of Agile India, got opportunity to interact and rub shoulders with multiple thought leaders in the space of Agiity.
 
I also did present a paper with Alok  Spee2 Value..  you can watch the video here
 

Speed-2-Value Abstract

More connected consumers, automated processes, and sophisticated analytics place unprecedented demands on IT functions. Many Enterprises are struggling to cope-up, as they seek to deliver on new demands by adding piecemeal elements to their existing operations. This is easier said than done. Reinventing the IT function at Global Enterprise requires far-reaching changes, from talent to infrastructure, tools, delivery models, partnership model. Speed to Value brings a holistic view of IT across the value stream, Plan- Build – Run and   brings strategy & levers, to 'renew' Enterprise IT to be responsive and help Business in realizing the business cases quickly. Key themes discussed in the session were about challenges related to large and complex Enterprise IT,. This session was well received and gave participants insights into the challenges faced by large Enterprise IT in their quest to accelerate Business Value Realization, key levers such as Lean thinking, Design Thinking, Value stream orchestration, Enterprise Agile, DevOps, and IT4IT and the approach for Speed-2-Value.

~ Pras 

 
 

Re- (New) IT for Digital world


 

Two decades back Nicholas Negroponte In “Being Digital”, book on the future of digital technology, talks of the transformation of the world from atoms to bits, a transformation he terms irrevocable, irreplaceable and exponential. We are witnessing Nicholas prediction in coming to reality.
The new Global Enterprise paradigm is increasingly shifting power into the hands of the end consumers. This empowerment will make consumers more connected, intelligent, more capable of taking good decisions, and certainly more demanding. 
Technology has blurred the lines between the digital and traditional methods of dealing with a consumer of any Global Enterprises. The Business Process and IT is no more separate, in most of the industry verticals the Business is driven by IT.   Constant Innovation around IT has become the new normal to the Enterprises to meet rapidly changing consumer expectations and behavior dynamics.
There will be a constant demand from the consumer for compelling IT experiences and stories. Consumer tend to switch places where he is more empowered, also switching cost is becoming more negligible across industry verticals.
More connected consumers, automated processes, and sophisticated analytics place unprecedented demands on IT functions. Many Enterprises are struggling to cope, and they seek to deliver on new demands by adding piecemeal elements to their existing operations.  This is easier said than done. Reinventing the IT function at Global Enterprise requires far-reaching changes, from talent to infrastructure, delivery models, partnership model and will takes multiple years to complete. Business and consumer is not ready to wait for multiple years. The only way we can meet their rising expectations is through a dual approach of renew and new, where we transform existing systems across the IT stack - from infrastructure to applications - to yield higher efficiency and a much better experience, while creating completely new systems to deliver what the consumer desire.
Fortunately, companies can adopt an approach that delivers results quickly while still reshaping IT for the long term. This two-speed approach requires first building a “high-speed” IT function to work alongside the existing IT function, focusing on one or two valuable business areas such as web and customer relationship management
Technology has blurred the lines between the digital and traditional methods of dealing with a consumer of any Global Enterprises. The Business Process and IT is no more separate, in most of the industry verticals the Business is driven by IT.   Constant Innovation around IT has become the new normal to the Enterprises to meet rapidly changing consumer expectations and behavior dynamics.
More connected consumers, automated processes, and sophisticated analytics place unprecedented demands on IT functions. Many Enterprises are struggling to cope, and they seek to deliver on new demands by adding piecemeal elements to their existing operations.  This is easier said than done. Reinventing the IT function at Global Enterprise requires far-reaching changes, from talent to infrastructure, tools, delivery models, partnership model.

~Pras

 

Friday, August 16, 2013

Why blame and critique #SAFe?


 This is my response to #Ken ( #Scrum ) and # David (#Kanban)

Everyone has an opinion and everyone has the right to share it, creative criticism is a welcome. I am sure there are more room under Agile umbrella.
“Being a consumer of Agile  ( I find a difference in perspective people using Agile and people use Agile for living), it’s about mere commonsense on what is required to bring a business excellence in the given context.  It’s a no brainer that problems plaguing large-scale Enterprise include communication and coordination errors at multiple levels people, process  as well as technology integration and infrastructure issues.  In large Enterprises Programs are complex with multiple LOB/ teams / legacy involved, also importantly  large programs are driven by disruptive technologies like Mobile, cloud etc..,   

Synchronization of multiple touch points and early integration testing form the two key ingredients in large-scale programs, and SAFe suggest ways to solve many issues that may arise during these stages – Portfolio->Program->Team.

It’s quite natural  that people look at something which  resonates to their context.  The timing and messaging of SAFe hits bulls eye, no wonder it’s the talk in the town.  You asks CIO of  any large organization  ( fortune 100 -50), what bothers them is show me the success of Agile? Let us wait and watch if SAFe is able to show something, as any consumer does, we will look for a new FACE..”
 
Cheers
Prasad

Thursday, June 20, 2013

SCRUM Fails!


For me Standup is an impidement? What about you?

Couple of years back few of my friends ( Naresh and Sandeep) from Agile community did a very different presentation in one of the Agile community meet ups on “Agile WTF (Way To Fail)”. I am trying to bring  clues from that talk to discuss  in  our context.  With few interaction with folks who do Agile here, I find various "agile" practices and which have become the dogma and ceremony that has crept in.

Agile is round the corner for more than a decade, Well, we need to  question if the practices defined a decade ago are still applicable? If yes, have they evolved since? What are some of the original creators of these processes practicing today? 

I randomly asked few, why are we doing ‘Daily Standup’ ? Answer : ‘SCRUM’ says..  without having a rational and value why are we doing standup? Because other teams are doing?  KenShwaber told to daily standup  when there was

a)      no integrated web based ALM with full visibility, traceability and transparency,

b)      there was very limited ability to do continuous delivery and frequent integration

c)       Social engineering  and mobility was at a  very primitive state then

 

Today we have team members who make 50 tweets and at least 100 FB updates every day, starting from boarding the bus to…..  .

If there is a social contract among  the team,  to the context of project there could be un conditional number of updates and tweets. With great collaboration eco systems around, what is the relevance of daily stand up. I understand a context, where team is distributed, need to have a sync.   What is the purpose of stand up? To know what I am working on, where could be the dependence, what support I need, what I am stuck on, what I have planned. If you need a support or help or letting others   know that  you are breaking the code , why should you wait till  the Standup meeting to tell that?

So, in todays connected world, if we create a social eco system including clients and other stakeholders and empower team  to be natural as real  social animal,  Standup is an Impediment

Team can form a unstructured data repository, learning can be in the context. So tell me one reason and a rational that I should ask the team to do ‘Standup’ ?

 

I am ready to take all beatings, but you should convince me..

Saturday, May 4, 2013

A thread to real Agile


 
"Manage well”.. I am sure there is no on here who have not received this wish/advice. Mange well in exams, games, play, projects, ‘spouse’ etc.. did we manage well ?? or why could we manage well.. was there any secrete sauce to ‘Manage well’ ?

So what is managing well means for you??

Here are my take on this generous wish / desire ‘Manage well’..

More than a wish for us it is a desire to manage well.., because we equate this to Success, some successful satisfaction ( I will write something about Successful satisfaction later)

So, coming back to ‘Manage well’, we need this when we are in a situation, like exam, project, job, marriage, games etc… and in every situation what are we going to ‘Manage’, nothing but ‘Variables’

So when we are in a situation,

1. Certain variability we know

2. Certain we do not know

3. Certain variable we know that we don’t know about it

4. There are many variable we don’t know that we don’t know

Now let us reflect situations we really managed well and we were successful, the reason is we are in complete cognizant about 1 & 2. Why in some situation we are less successful, because it is more of 3 & 4..

Let us take a situation, Indian cricket team visiting Australia, they are going for their first test match-- every one wishes Indian team to ‘Manage well’ ( this is just an hypothetical example )

What variability Indian cricket team know – bouncy pitches, super-fast bowlers, huge ground , less ground support

What variability they do not know - which players are in great form, how much grass they leave, how many pace bowlers they pick, winning a toss what Clark is going to do..

What variable they know that they do not know - how much runs Australia will score in first innings, how lenient Umpire is about LBW etc.

What variable they don’t know that don’t know - how to run between wicket L, how to apply and spend time in crease ..

So, how Indian team can be victorious in the first test? I leave it your imagination !!!

So from a personal front, when you are in a situation try do a mapping of the critical variables.. the more you are in 1 & 2 zone.. you are in Control ( again I will write more about Control later). We are at best when we feel, we are in control of the variables.. so what you do when you are in not in control ??

So IT business perspective,

In the first phase of IT revolution, we were trying to automate certain business process using computer programs / packages. Where IT folks were clear about what business problem ( variable) they are trying to automate and what is its solution (variable). Only very few programming language and package existed. No focus on efficiency and effectiveness of automation. Automation itself was great USP..

In the second phase of IT revolution, business problem remain known, solutions were challenging, more focus on performance, usability, security. Many solution alternates, cost implications and maintains issues ( all of these are variable ). IT group started losing control, started implementing ‘process’ frameworks / standards etc… , got a feeling they are back in control, do they ??

According to me we are in third phase of IT revolution, where there is no distinction between IT & business process. Disruptive technologies like Mobility , cloud, social engineering, Internet of things drives business and its consumer behavior. So we are behind unknown problems and unknown solutions, highest of 3 & 4. We are in total loss of control J, so how do we ‘manage well’?

The situation we are in third phase, lot of variables makes us un comfortable , create fear failure… .

So here is ‘Mantra’ to regain control

· Short feedback loops, frequent learning cycles and early feedback [ this helps to un cover many 2, 3 & 4)

· Let us fail early and effectively – let us be empirical

· Better interaction on Business users and IT folks – are we building right things

This ‘Mantra’ is nothing but Agile / lean philosophy.. so, Agile gives us insight about variability’s and very cycle / sprint will uncover many 3 & 4. Thus help us to gain back the feel of control and hence ‘MANAGE WELL’ in turn to SUCCESS..

So Agile is not the end it is a means via we do manage well…

Will connect with you folks on my random & crazy thoughts

So, manage well…

 

Monday, April 1, 2013

Building right product a new mindset

Today most of the Software is build for a domain where we are not sure about both problems and solution.  So there is uncertainty in all phases of software development. In the context of software development being a complex adaptive systems, how testing should align with this changing paradigm of known to unknown?  It is calling for a fundamental change in the approach of a test engineer’s role &responsibility. The test objective, strategy & approach needs to transform to address the reality in the world, cannot be inward out! Testing should be the way to transform Unknowable – Unknown – Knowable – Known cycle.  It becomes important to ask, are we testing the right  ‘it’ before testing ‘it’ right. 
Recently I read few books The lean startup, four steps to the epiphany, Pertotyping at work .  This enabled me  to  question and provoke  our fundamental beliefs of software product development   and provided views and perspective of  - Complex adaptive systems, Cyfen learning dynamics, ‘Pretotype – Google way’
By the way I become a big fan of this http://www.pretotyping.org/pretotype-it---the-book. Fake it before make it...
 

Thursday, August 2, 2012

New School of thought for QA


The end of the road for the test phase?

There is much debate about how testing will be organised in the near future. The testing profession has evolved from the very first time developers started testing through to separate test phases and independence and then to collaborative testing.

The waterfall method, which is still being used by many organisations, prescribes an extensive final test phase. Another significant feature of waterfall is that the software development process is organised with several sequential periods, or test phases, in which a dedicated group performs specialised tests. In this context, the term ‘test phase’ can be defined as a group of jointly executed and controlled test activities. The testing within each phase may be more or less structured and formal, but the test activities within a test phase are bound by common objectives and the same focus or system boundaries.

Afterthoughts

There is little value in a quality assessment that is too late. Within the waterfall method the testing is often tested until just before the deadline. Due to high workload the test report is written afterwards when the system is already in production. What is the value of remarks and comments at this stage? What should the project do with bugs that cannot be restored, since the deployment is already a fact?

Even when testing is done at early stages, such as with the system test, results are coming in too late. The fair is already over. The programmers have done their work and want to start something new, but must wait until the testers make their statement about the quality, often accompanied by a litany of bugs.

Customer experience is a key performance indicator (KPI) that is gaining popularity with our stakeholders. Organisations put the customer rating at the centre of their dashboard. Although bugs are a threat to customer experience, the perceived value of a full bug tracking system depreciates quickly.

The aim is not to demonstrate the differences with the specification, it is to have a satisfied customer. Agile development aims for ‘right first time’ and has therefore a large focus on early detection and quick resolution of errors. The user is involved in the development and cooperation is more important than following a formal specification. This reduces the need for an independent quality judgment at a later stage.

The development cycle is shortening

The life of software is becoming shorter due to rapid innovation. Consequently, we should develop our software faster also. Kent Beck provides a clear prognosis at the USENIX Technical Conference.

In the coming years the deployment cycle will decrease from an average of once a quarter to releases on a daily or hourly basis. For testing this has two direct consequences. First, test must be performed quickly. You cannot test for one month when the software is due to be released next week. Secondly, the phasing of activities gets blurred. Testing is done continuously and by everyone. There is no longer room for a separate testing phase.

A shift to operational assurance

For many organisations the test phase is still important but in Agile organisations there is a shift in emphasis. We see that testing is an activity that is conducted by many parties: developers within the sprint, business architects during design and real users that perform beta tests. Quality attributes like usability, durability and security are increasingly important and get attention throughout the project. This is in contrast to the traditional test phase in which a group of independent testers, urged to speed by a fast approaching deadline, execute their functional tests.

The above description shows a clear shift of formal testing phase (especially at the end of the development process) to a continuous process involving many disciplines. Linda Hayes indicates that there is a shift from quality assurance to operational assurance. In this the quality assessment no longer has central place, but the support of the operational process has. On the basis of the above arguments, it is clear that one of the ‘victims’, of this shift is the separate testing phase.

Note that the above arguments question the health of the separate test phase, and argue it to be dying dinosaur. Between the lines you can read that testing as discipline is far from dead. It will be organised differently and other disciplines are getting involved. Although things are changing for sure, the above arguments are only one side of the coin. Are there arguments that plead for a separate test phase and the end of the cycle? Yes, there are!

Arguments for a test phase at the end of cycle

In the following paragraph I will share some arguments that plead for a separate test phase.

Although it is desirable to maximise early testing as much as possible, not all tests can be done upfront. Often it is just not possible. Unit and system tests only check the quality up to a certain level. Due to appification and an increase in system couplings, the system chains get longer.

Using adequate simulations and by working with trusted components a lot of errors can be solved before integration, but these measures will never replace a true integration test. Experience teaches us that when two systems interact for the first time, often unforeseen problems arise. A testing phase at the end prevents these problems from occurring while being in operation.

The supplier has other interests

Wherever development work is being outsourced, organisational boundaries arise. On either side of this boundary parties have their own interests. And they might be different and exclusive. For political reasons or due geographic spread it is difficult for the accepting party to have real insight in the activities of the supplier, therefore control and checking by the acceptor is a necessity.

Preferably this are done during the project and in cooperation with the supplier, but formal acceptance means that there is should be a critical examination once the goods are delivered. Although the weight of this activity may vary based upon the trust one has in the supplier and the risk involved, it pleads for a small testing phase at least.

Politics rule

Apart from the question of acceptance, when organising testing one has to have an eye for the role that politics has in the organisation. Increasingly, organisations are expected to meet compliance standards like Basel, SOx, SEPA (just to name a few). This forces compliance testing, and makes demands on the formality of the testing activities. Besides it is often desirable to have a shared responsibility and create a wide commitment. Both can be achieved by involving stakeholders and management in testing. Such a test phase therefore has a political purpose.

As mentioned, quality attributes such as security, performance, durability and user friendliness become increasingly important. Experience shows that these specialised tests are often best organised separately. Usability, Performance testing, and especially reliability testing seldom fit within a two week sprint. If you organise Beta Testing, a longer run will lead to greater coverage, reasons for these tests to be organised in a – you guessed it – separate test phase.

Legacy

Almost all organisations have to deal with legacy. Agile development, continuous integration and testing are all right, but bear in mind, that not all of the software is suitable for this mode of development. In particular, legacy systems can best be adapted in a traditional development way.

According to Ken Beck various types of systems require different testing approaches. It may therefore be effective to choose for different test approaches. These coexist within the same organisation. Besides legacy systems, there are also legacy organisations. In these organisations, the technique does not determine what is possible, but the culture and available knowledge does. Agile development requires the right expertise and mindset. Not every organisation is ready for this.

In life-critical systems the above arguments apply even stronger. If lives depend on it, the organisation is bound to tackle as many problems as possible by fully integrating testing into the development, and to have the necessary objective test moments. Thus, the two opinions merge into one other and coexist side by side.

Best of both worlds

We have seen that there are arguments for and against separate test phases within software development. I do not think there is value in forced decisions for or against. We should not cling to the known test phases just because we are familiar with them. Neither is it desirable to throw away the old approaches. Current developments will lead to many changes. It is important for testers to track these developments and to consider what its consequences are for the testing profession and the way we do our work.

In my view, the job gets more colourful, versatile and challenging. We get new tools and options. Test strategists will have to think about the contribution they want to make to the organisation and what objectives we pursue with our activities. On this basis we can make choices.

Let old and new ideas come together. This will result in testers that sit beside developers to reduce and rapidly detect errors. This will also lead to testers that are working in separately organised test phases, whenever this is more efficient.

I can think of situations where, for example, all activities related to a certain risk group are combined in a dedicated test phase. Proper business alignment dictates that the output of our test activities are closely related to the information needs of the business. Regardless of the moment in time that particular test activities are being performed, it can be rewarding to organise them separately. This holds for all testing activities that contribute to the same insights and information. By doing so, the test coordinator becomes the responsible person that, on behalf of the business, ensures intelligence and comfort for one or more key focus areas.

The test phase is far from dead, but it will increasingly be defined and organised in a different manner. I think that’s just fine, as long as we keep aligned with the needs of the organisation, we continually challenge ourselves to deliver maximum added value and contribute to operational excellence.

 Happy testing

Prasad