A 'clever' blog of a 'free' mind
Posts tagged application support
Agile ready support processes – Acceptance Into Service
01090 days
by Swapnil
in App Support thoughts
There is a lot of push currently within the IT organizations to use the ‘Agile development’ methodology for delivering new products & projects. The customer demands changes rapidly and that is what precisely the agile development framework provides to the service providers.
But .. and the big but is that the ‘agile development framework’ talks only about the development of a software and does not talk about the necessary processes that are required post go-live and related testing efforts to accept the product into service.
Yeah, I am precisely talking about the support processes that need to be aligned with development efforts and must be completed before the go-live of a product. In fact, I am talking about “Acceptance into Service” testing that needs to be done before the product is accepted into the service.
In a traditional world when the development follows the waterfall model, the window for the acceptance service is normally reserved a week before the scheduled go-live to complete the activities such as knowledge handover to the ASG teams, create support documents and related testing. However, the agile framework does not allow such window for doing the acceptance testing at the end of the development cycle and expects the teams to collaborate while the development is being carried out.
The following table precisely summarizes how I perceive the difference between the way Acceptance into Service will work in the Agile way as against the traditional way.
| Waterfall Model | Agile Model |
|
|
In a nutshell, I would like to summarized my proposed Agile method for performing the acceptance into service is as follows,
- AIS is no longer a separate phase but a joint effort of delivering bug free, support ready & self aware application on production
- High level AIS process
- Agree on the acceptance criteria upfront
- Verify compliance
- Understand the application as it evolves
- Build the support repository as the application evolves
- Build the support document together
- AIS tasks are now part of the delivery sprint
- Resilience testing is done as a separate phase if need be
- AIS is a process to help delivery teams deliver better software – than pointing mistakes / finding errors
Hope you find the above useful as a summary.
This is of course my first post of this series and of course I will try to post more information on the agile processes and related testing mechanisms and how they would help you test the applications thoroughly prior to being accepted into service for support.
Outcome based results & individual accountability
01093 days
by Swapnil
in Business thoughts
Whilst on the lunch table today, one of my colleagues in other project mentioned the possibility of our company introducing the performance based accountability factor in one’s salary and pay cheque and I was really stunned with the way things are now going downwards..!
Essentially the point my colleague was making that there are discussions happening within the organization to make individual more accountable by introducing ‘fines’ against someone who would make mistake while implementing the product or change that would eventually lead to any monetary losses to the company. This is probably something that was never heard of for the permanent employees, possibly has happened and happens for contractors though !
I think this may or may not be a wise step to do, especially within the Production Support and Application Support environment where teams are expected to work 24×7 under a pressure cooker scenario.
If taken in a right spirit (which normally does not happen), it may help keep the people on their toes whilst doing the critical job and make them extra cautious and avoid obvious mistakes. I am afraid, it might turn out to be a disaster if individual people are blamed and put to sword, in front of other colleagues, it might turn them off and leave them demoralized. Its like dishonouring individual’s contribution to the projects, however successful, if they make one single mistake.
I remember one incident in the past that happened with one the other projects where one of the DBAs accidently deleted few tables from Production database instead of the pre-production environment. This led to the production portal being down for 3 consecutive days whilst the recovery was ongoing in background from backups etc. This issue, forever left a blemish on his career and he was always perceived as ‘the person’ who took production down, rather than how good this person was and what previous contribution he made in the projects. He was immediately sacked from his role and probably had left the company as a consequence.
Whilst, I am in favour of stronger accountability across the management chain and down to the individual, I am strongly against putting the blame on one single individual or a group of team members who work day / night to ensure that the project stays on track and the product is delivered on time. Normally the rewards are taken by the management, if the team does brilliantly, but all the issues and problems cascade to the down-most possible level of organizational hierarchy.
In my opinion, the people within organizational chain, who are directly involved in the outcome of the project, should all take their share of blame. However, traditionally what is seen in the organizations (as depicted in the picture below), the accountability of the project lies most with the lowest leagued people, whereas the bonuses earned by Sr. Management are the highest !
Picture – Traditional models for accountability vs year end bonuses paid !
Whilst I do not want to make any recommendations with regards to the suggested model for introducing the ‘fines’ to individuals, I think the blame should be shared with all those people who are directly involved in making the project success. Be it the person who is developing it, the one who is doing quality check, the one who is project managing it, the one who is actually implementing it and of course the people who are providing infrastructure to make whole thing work !
As usual, rest is left to you to think and make your own judgement !
Top 5 myths related to application support domain
01097 days
by Swapnil
in App Support thoughts
Did you ever notice that in a multi-service oriented IT organization, that delivers new projects / products as well as provides IT support services to customers, more focus is normally given to delivery of products than providing high quality maintenance & support services? Well, if you have, then you are not the only one!
What I have seen at least in the Indian IT companies is the poor comparison given to the professionals working in the IT service support domain than to the professionals working in delivering new functionality to the customers. I suppose the roots of such unfair comparisons are in few myths that are present in the IT area.
- Call centre perception – Yeah, most of the people I spoke with did not have any idea when I asked and interviewed them about working in support projects. I asked them ‘What do you think working in support means for you?’ The quickest answer I got back is ‘I think it’s like working in a call centre, you need to be on phone all the time and answer customer queries. I am not interested in becoming a phone operator!’ Well, to a certain extent they are right. If you are providing support services from an off-site based location (Offshore or nearshore locations) then yes it does involve lots of speaking on phone. But if you look the way IT is working, speaking on phone, joining conference calls etc., has become just the way of work.
- You do not learn much when you work in support - This is the most common excuse given by professionals (at least young professionals) when they are asked to work on support projects. They feel that working in support does not offer them opportunities to enrich their skills in technical area. I certainly do not agree with this! In my view, working in the support function just gives you an opportunity to view at things differently and gives you a closer and practical look on how projects work on production platform and how a product is used in practice. You get to know the project and products from a close angle and you are always on the edge to keep the software / service working. Imagine how it would be like to have an outage on a banking site!
- You do not feel enough challenged while working in support – This is another common myth that makes house in the minds of fellow software professionals. They feel that working in support projects does not offer enough to challenge their intellectual wits. They feel that the work is repetitive and routine and thus they would get bored after some time in working in the project. I certainly do not think so! Ask this question to the people who support the online trading on bank website, or stock market website where even a minute’s outage may mean you lose millions of dollars in business. Is this not a challenge to keep them running?
- My professional growth will stagnate – Lots of people whom I interviewed for projects often complained to me that if they join the support project, their growth opportunity will be limited and they would get stereotyped for rest of their career. To the certain extent I agree with later part (i.e., stereotyped) but definitely do not agree with the first argument. The growth of the individual in an IT organization depends on how the person senses opportunity and makes use of it and not on what project he or she works on. After all, you are likely to get a better recognition if you save a bank site from falling over than writing a piece of software!
- My value amongst my peers will go down! – This is one of the silliest excuses I have ever come across; indeed I did come across this. The person who was telling me this was saying that he will feel inferior compared to a person working in a delivery and writing Java code. Fuf.. ! I did not have any answer for this, but all I would say is the inferiority is in the mind and depends on confidence of one rather than natural capability.
Interesting enough right? Let me know if you have come across any more myths about professionals saying no to work in support.
As earlier, pasting here a fantastic Dilbert comic strip that gives perfect example of how the world perceives of the Tech / Application support !
