Thursday, May 27, 2010
Monday, April 13, 2009
Project team structure - The Vedic way
Whenever we look at any project, we invariably see the various teams taking the center-stage at various point in the project life cycle. Where do we get this team structure, is it part of modern project management parlance? No necessarily, as we delved into our Indian vedas, we found similar description in the context not so far away from our existing team structure requirements. Lets me share some more...
In our vedas, it has been documented that people are of three basic types - Gyanyoga, Rajayoga and Bhaktiyoga. The Gyanyogis are the ones inspired by intellect, Rajayogis are inspired by Leadership and strategy and the Bhaktiyoga people have complete faith in their masters and are inspired by their devotion.
The start of any new project stems out from an idea that is mulled over and over to give a proper shape and plan. This is done by the people who belong to Gyanyoga category, these are the innovators and intellectuals. In a modern project these will be people in the board of directors or the advisers.
The idea is then converted to execution plan and the team of people are entrusted with the execution within the overall vision and strategy of the project. These are the Rajyogis, we call them the managers in our modern projects.
The team of people that will do the actual execution of the project should have full faith in their managers and should be devoted to the work that is assigned to them. The managers manage their day to day work to evaluate to ensure that the overall objective of the project is met. These people are Bhaktiyogis, also called team members in modern project teams.
So you see our vedas can educate us in all aspects of our lives including the professional...
In our vedas, it has been documented that people are of three basic types - Gyanyoga, Rajayoga and Bhaktiyoga. The Gyanyogis are the ones inspired by intellect, Rajayogis are inspired by Leadership and strategy and the Bhaktiyoga people have complete faith in their masters and are inspired by their devotion.
The start of any new project stems out from an idea that is mulled over and over to give a proper shape and plan. This is done by the people who belong to Gyanyoga category, these are the innovators and intellectuals. In a modern project these will be people in the board of directors or the advisers.
The idea is then converted to execution plan and the team of people are entrusted with the execution within the overall vision and strategy of the project. These are the Rajyogis, we call them the managers in our modern projects.
The team of people that will do the actual execution of the project should have full faith in their managers and should be devoted to the work that is assigned to them. The managers manage their day to day work to evaluate to ensure that the overall objective of the project is met. These people are Bhaktiyogis, also called team members in modern project teams.
So you see our vedas can educate us in all aspects of our lives including the professional...
Thursday, March 12, 2009
Recession Blues - Companies, think twice and retain your employees...
The market is very turbulent and news of people getting laid off just does not seem to end, in fact the trend seem to be increasing. Pundits are saying that this is just the beginning and the gloom may last till 201o end. What should a company do if they do not have enough work for their employees? Should they feel themselves to be helpless and fire their people. For some companies it is an opportunity to 'cut the fat' and only retain the best talent that they have. Some have planned lay-offs and others are just doing it as knee jerk reaction to the market sentiments as the measure to cut cost. Is this the only option they have - the western model of hire and fire? We think this is not the right approach. After all it costs a lot of time, effort and money to train people - technology-wise, culture-wise and business-wise. Hence when the tide of recession turns, the company will need to go hammer & tongs to recruit people and reinvest time, effort and money to train the new recruits. Should there be some method to this madness and mayhem? We say yes, in such times companies need to be more sensitive to their employees, after all we are in India and companies should take this opportunity to truly treat their employees as family members. Here we propose a conceptual model to come out as a winner and leverage these hard times to imbibe our Indian cultural ethos in our companies and not just survive by firing people and cutting cost.
Numbers attached to this model:
1. Retain the employees with salary cut.
2. Find the differential between the amount saved if employees fired (A = All salary) vs. retaining employees with salary cut (C = Salary Cut). D = A-C.
3. Create of pool of such people and assign tasks with quantifiable results. (R = Worth of results).
4. We need to keep R >= D to make this work.
Variables affecting the model:
1. Resource pool count fluctuation
2. Unplanned entry and exit to the resource pool (temporary project assignment, resignations)
3. Other costs associated with the resources (seating cost etc.)
4. Top management support and commitment.
5. Measuring the results and converting it to quantifiable numbers
Numbers attached to this model:
1. Retain the employees with salary cut.
2. Find the differential between the amount saved if employees fired (A = All salary) vs. retaining employees with salary cut (C = Salary Cut). D = A-C.
3. Create of pool of such people and assign tasks with quantifiable results. (R = Worth of results).
4. We need to keep R >= D to make this work.
Variables affecting the model:
1. Resource pool count fluctuation
2. Unplanned entry and exit to the resource pool (temporary project assignment, resignations)
3. Other costs associated with the resources (seating cost etc.)
4. Top management support and commitment.
5. Measuring the results and converting it to quantifiable numbers
Wednesday, February 25, 2009
Gaps in Quality Processes in our daily lives
Once we know 'What' is to be done, 'How' becomes a very important aspect... rather THE IMPORTANT aspect... why I say this is because 'how' we do it decides the Quality of the 'what' we are doing.... Here 'what' may be anything... I mean 'ANYTHING'.... anything from the time I wake up to the time I hit the sack at the end of the day... it may be related to my brushing of teeth, eating my food, taking bath, driving to work to doing each and every task at my work place to.... And in Quality parlance, this 'How' is called 'Process'.... Hence 'Processes' are 'THE IMPORTANT' things in all aspects of our lives... Unfortunately we seldom realize this quality perspective consciously or even think about it, and this leads to what I term as "Quality By Chance"... Many a time this leads to poor quality in our daily lives - personal. professional and social... Many a times the immediate damage it causes might be minuscle but some times it is ever increasing if nothing is done about it, and may hurt us badly in long run. We typically try to adjust to these problems instead of finding solutions to them, at least not in the early stages.
Let's take a typical day of our life and see how following the quality processes or lack of it impacts on the overall quality of our lives. Starting early in the day our car-wash boys, there are about 350 cars in the compound and this group of 25 boys wash them everyday. They do not have any planned leaves and they just take off whenever there is a need or just like that. They can coordinate amongst themselves and take planned holidays and also the cleaning of cars will not get affected. Other part of it is that they all do washing individually to carry out every task, while this could be devided amongs them e.g. group1 can do the dusting, then group2 would do the wet-washing and then group3 will wipe and dry. This can happen, with a plan with parallel tasks and save on time and effort and also improve the quality of car washing.
The next task is at home, where set of 40 'Bais' (Housemaids) do the cleaning of around 300 flats. There work is highly unstructured and always tend to have some or other scheduling problem. Both, the employers and the 'bais' need to have better communication and structure to their tasks so that the work could be done more efficiently, at the right time and within allotted time.
After this we are ready to leave house for work, if we use our own transport (self-driven or driver), there are umpteen instance on our way where we get impatient (putting it mildly) and try to steal our right of way. This behavior is common across all section of drivers, literacy or financial standing not withstanding, nobody gives a second thought while blatantly not followingh the rules or processes set by the traffic authority. If we give way to others and follow the traffic rules, it may seem like that we are taking longer but it's overall effect would be saving us lot of time. I am sure this can be mathematically, scientifically and socially proven.
If we take autorickshaw, we will struggle to find the generous auto driver who would do ud the favor to take us in the direction where we want to go. If we are not lucky, we could be hunting for the ellusive auto for long time. I know there is an RTO rule that the autorickshaws need to ferry the pasengers whereever they demand to go but I also understand that it is not possible all the time. The simple solution to this could be that every auto carry a small sign of the route they are interested in goin towards. This will avoid the unnecessary haggling with the auto drivers and make our lived easier and less stressed.
Let's take a typical day of our life and see how following the quality processes or lack of it impacts on the overall quality of our lives. Starting early in the day our car-wash boys, there are about 350 cars in the compound and this group of 25 boys wash them everyday. They do not have any planned leaves and they just take off whenever there is a need or just like that. They can coordinate amongst themselves and take planned holidays and also the cleaning of cars will not get affected. Other part of it is that they all do washing individually to carry out every task, while this could be devided amongs them e.g. group1 can do the dusting, then group2 would do the wet-washing and then group3 will wipe and dry. This can happen, with a plan with parallel tasks and save on time and effort and also improve the quality of car washing.
The next task is at home, where set of 40 'Bais' (Housemaids) do the cleaning of around 300 flats. There work is highly unstructured and always tend to have some or other scheduling problem. Both, the employers and the 'bais' need to have better communication and structure to their tasks so that the work could be done more efficiently, at the right time and within allotted time.
After this we are ready to leave house for work, if we use our own transport (self-driven or driver), there are umpteen instance on our way where we get impatient (putting it mildly) and try to steal our right of way. This behavior is common across all section of drivers, literacy or financial standing not withstanding, nobody gives a second thought while blatantly not followingh the rules or processes set by the traffic authority. If we give way to others and follow the traffic rules, it may seem like that we are taking longer but it's overall effect would be saving us lot of time. I am sure this can be mathematically, scientifically and socially proven.
If we take autorickshaw, we will struggle to find the generous auto driver who would do ud the favor to take us in the direction where we want to go. If we are not lucky, we could be hunting for the ellusive auto for long time. I know there is an RTO rule that the autorickshaws need to ferry the pasengers whereever they demand to go but I also understand that it is not possible all the time. The simple solution to this could be that every auto carry a small sign of the route they are interested in goin towards. This will avoid the unnecessary haggling with the auto drivers and make our lived easier and less stressed.
Friday, December 19, 2008
Ego of testers - fuel to exploratory testing?
Why do some testers feel that they do not have to follow the test script blindly and they know better than that? Is asking them to stick to the test script, insulting to their intelligence? I am not too sure about the answers as it has many psychological and social layers.
I think there is a need to identify the inherent nature of any individual tester, if some feel that they would do better doing exploratory testing then we need to respect that. At the same time, effort must be made to validate their claim to assess their aptitude. Those testers who wish to be 'free-birds' should be not be forced to stick to pre-decided test script, it will certainly suppress their creativity. While we go about doing this, we got to ensure that we are not producing 'rogue-testers' (apologies if anyone is offended by this term). As saying goes from Spider-man movie, 'With great power comes great responsibility', so we need to be careful that we are not giving power into reckless hands. I would not like to use the term 'adhoc testing' as synonymous to Exploratory Testing, 'adhoc' for me signifies careless, sloppy and chaotic, things we do not relate to testing.
Now who would be ideal candidate for exploratory testing: someone who is well-verse with the application functionality and design, someone who has strong intuition, someone with strong analytical skills, someone who can design and modify the test design on the fly.
Exploratory Testing need not be against the ides of test scripting, rather it should be used in combination with test script based testing. And each of these teams would require testers with specific temperament and ability for successful execution.
I think there is a need to identify the inherent nature of any individual tester, if some feel that they would do better doing exploratory testing then we need to respect that. At the same time, effort must be made to validate their claim to assess their aptitude. Those testers who wish to be 'free-birds' should be not be forced to stick to pre-decided test script, it will certainly suppress their creativity. While we go about doing this, we got to ensure that we are not producing 'rogue-testers' (apologies if anyone is offended by this term). As saying goes from Spider-man movie, 'With great power comes great responsibility', so we need to be careful that we are not giving power into reckless hands. I would not like to use the term 'adhoc testing' as synonymous to Exploratory Testing, 'adhoc' for me signifies careless, sloppy and chaotic, things we do not relate to testing.
Now who would be ideal candidate for exploratory testing: someone who is well-verse with the application functionality and design, someone who has strong intuition, someone with strong analytical skills, someone who can design and modify the test design on the fly.
Exploratory Testing need not be against the ides of test scripting, rather it should be used in combination with test script based testing. And each of these teams would require testers with specific temperament and ability for successful execution.
Friday, December 5, 2008
Agile Manifesto
The Agile Manifesto reads as follows:
"We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value [the following]:
- individuals and interactions over processes and tools
- working software over comprehensive documentation
- customer collaboration over contract negotiation
- responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more."
The Agile Manifesto has a list of general principles attached to it.
"We follow these principles:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- We welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- We deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- We build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity—the art of maximizing the amount of work not done—is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
What's your interpretation of this?...
Tuesday, December 2, 2008
Agile Testing - Only for Agile Development methodology?
Before I introduce the new paradigm of the Agile Testing process for ALL development methodologies (including Agile), I am put across my thoughts over the traditional Agile Testing practice which exists in the realm of Agile development.
Simply put, it is the testing practice that follows the agile manifesto, treating development as the customer of testing. In this light the context-driven manifesto provides a set of principles for agile testing.
First let me list the Agile Development Methodologies that I a aware of:
Developers write unit tests before coding. This
- Motivates coding
- Improves design (reducing coupling and improving cohesion)
- Supports refactoring (Refactorting --> “Changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure”.) - Make the simplest design that will work. Add complexity only when needed. Refactor as necessary. Refactoring requires unit tests to ensure that design changes (refactorings) don’t break existing code.
Many open-source test tools have been developed to support this. for e.g. xUnit
Pair Programming
All production software in XP is built by two programmers, sitting side by side, at the same machine. This practice ensures that all production code is reviewed by at least one other programmer, and results in better design, better testing, and better code.
Iterative Test-Driven Development
Extreme Programming is obsessed with feedback, and in software development, good feedback requires good testing. Top XP teams practice "test-driven development", working in very short cycles of adding a test, then making it work. Almost effortlessly, teams produce code with nearly 100 percent test coverage, which is a great step forward in most shops.It isn't enough to write tests: you have to run them. Here, too, Extreme Programming is extreme. These "programmer tests", or "unit tests" are all collected together, and every time any programmer releases any code to the repository (and pairs typically release twice a day or more), every single one of the programmer tests must run correctly. One hundred percent, all the time! This means that programmers get immediate feedback on how they're doing. Additionally, these tests provide invaluable support as the software design is improved.
Now lets look at Acceptance Testing
User stories (same purpose as that of use cases but are not the same) are short descriptions of features that need to be coded. One or more automated acceptance tests must be created to verify the user story has been correctly implemented. Acceptance tests verify the completion of user stories. Ideally they are written before coding.
Should users go along with this?
Some say that XP is an invitation to poor quality and an excuse for hacking. I think that XP is exciting and will improve the practice of testing in the industry.
Even better if we can have an independent Agile Testing process (that is 'independently agile') irrespective of the underlying Development Methodology... please watch this space for more on this.
Simply put, it is the testing practice that follows the agile manifesto, treating development as the customer of testing. In this light the context-driven manifesto provides a set of principles for agile testing.
First let me list the Agile Development Methodologies that I a aware of:
- Extreme Programming (XP)
- Crystal
- Adaptive Software Development (ASD)
- Scrum
- Feature Driven Development (FDD)
- Dynamic Systems Development Method (DSDM)
- XBreed
- Testing is the headlights of the project- Where are you now? Where do you headed?
- Testing provides information to the team- This allows the team to make informed decisions
- A “bug” is anything that could bug a user- Testers don’t make the final call
- Testing does not assure quality- The team does (or doesn’t)
- Testing is not a game of “gotcha”- Find ways to set goals, rather than focus on mistakes
- Test-First Programming
- Pair Programming
- Short Iterations & ReleasesRefactoring
- “User Stories" Acceptance Testing
Developers write unit tests before coding. This
- Motivates coding
- Improves design (reducing coupling and improving cohesion)
- Supports refactoring (Refactorting --> “Changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure”.) - Make the simplest design that will work. Add complexity only when needed. Refactor as necessary. Refactoring requires unit tests to ensure that design changes (refactorings) don’t break existing code.
Many open-source test tools have been developed to support this. for e.g. xUnit
Pair Programming
All production software in XP is built by two programmers, sitting side by side, at the same machine. This practice ensures that all production code is reviewed by at least one other programmer, and results in better design, better testing, and better code.
Iterative Test-Driven Development
Extreme Programming is obsessed with feedback, and in software development, good feedback requires good testing. Top XP teams practice "test-driven development", working in very short cycles of adding a test, then making it work. Almost effortlessly, teams produce code with nearly 100 percent test coverage, which is a great step forward in most shops.It isn't enough to write tests: you have to run them. Here, too, Extreme Programming is extreme. These "programmer tests", or "unit tests" are all collected together, and every time any programmer releases any code to the repository (and pairs typically release twice a day or more), every single one of the programmer tests must run correctly. One hundred percent, all the time! This means that programmers get immediate feedback on how they're doing. Additionally, these tests provide invaluable support as the software design is improved.
Now lets look at Acceptance Testing
User stories (same purpose as that of use cases but are not the same) are short descriptions of features that need to be coded. One or more automated acceptance tests must be created to verify the user story has been correctly implemented. Acceptance tests verify the completion of user stories. Ideally they are written before coding.
Should users go along with this?
Some say that XP is an invitation to poor quality and an excuse for hacking. I think that XP is exciting and will improve the practice of testing in the industry.
Even better if we can have an independent Agile Testing process (that is 'independently agile') irrespective of the underlying Development Methodology... please watch this space for more on this.
Subscribe to:
Posts (Atom)