Blogs >> Technology >>
A debate with Jim McCarthy, Microsoft Corporation.
When I say that Jim McCarthy did a great job in publishing the 21 thumb rules that decides the success of a software project, I am more keen today to make a casual connection of these principles to my past years of experience as a software engineer who was working for IT companies in India for outsourced project and today when I work directly with those clients in United States. I remember the day I was taking a training at Stabilix solutions on these thumb rules in early 2004, where nobody did ask any questions on those presentation slides. Are they all agree to what I tailored from Jim's principles?. Anyway even I did a mistake, I sent the presentation slides to all attendees two hour before training. But no worries, I'm sure nobody did open that before entering my training class, otherwise I could have got atleast a single question.. :)-
Let me put it this way, "Things which are not known are more at any stage of any software project, and that doesn't mean that we cannot deliver what our client wants. This is why today I see engineering as "Imagineering". Not sure what you think about that terminology, but tell me frankly, " What indicates success in your project development , progress or promises?".
Now have a look at Jim's 21 thumb rules and my thoughts are in blue color.
From Jim McCarthy, Microsoft Corporation:
Shipping great software on time is a difficult but not impossible task. Elements you think would count the most count for very little. Development methodology, process, technical prowess, excellence of tools and depth of project management skills all influence the outcome of a software development project; but nothing indicates success as much as the manager’s ability to focus on a few critical and conceptually simple things. These things can be expressed as rules of thumb.
Here I agree with Jim in the above statement, but I was wondering, wasn't that part of project management skills to identify those few critical and conceptually simple things?.
On Time
1. Don’t know what you don’t know.
It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you are things you pretended to understand but didn’t early on. At virtually every stage of even the most successful software projects, there are large numbers of very important things that are unknown. It is acceptable, even mandatory, to clearly articulate your ignorance, so that no one misunderstands the corporate state of unknowingness. If you do not disseminate this "lucid ignorance," disaster will surely befall you.
Human nature is such that we dislike not knowing things that are important to our well being. Since there is so much we don’t know in a software project, the nearly universal tendency among developers and their managers is to gloss over or even deny altogether the extent of their ignorance. You should reward and treasure those who consistently make themselves aware of the list of relevant things that are currently unknown. It requires mental and psychological strength to resist the normal human cravings for certainty and order. It especially difficult to believe in uncertainty when things have a veneer of orderliness, which is often the case. Pseudo-order is a maladapted defense against uncertainty.
Sometimes we must profess to know the things which are unknown at the time. But make sure that nobody else know it better before you manage to get to know the same. :)-
2. Get to a known state and stay there.
The function of QA is to know (and articulate) the quality of the product at all times in the development cycle. This should be achieved by abbreviated, repeatable tests conducted daily, and full product sweeps conducted weekly or biweekly.
It is not properly the job of QA to determine when a product is ready to ship; rather, the moment of shipworthiness in a product development cycle is evident to everyone involved, and is non controversial. This is because shipping has been the goal of the entire effort. Crossing the finish line, while it has intangible emotional and definite financial rewards, is no surprise when you’ve observed every single painful step toward it.
Agile methodologies serves this purpose upto some extend by making everything transparent. Having said that, what is this known state, is it a sprint backlog on which we all agreed upon after a scrum meeting?. I would rather call it a shared vision and corporate responsibilty to sail towards that deadline.
3. Remember the triangle.
There are only three things that you are working with as a development manager: resources (people and money), features and the schedule. Changing one has an impact on at least one other axis, usually two. It is a simple enough matter to mentally run through the sides of the triangle, or force others to do so, when discussing any part of it. Since the people, the product or the schedule is almost always what you’re discussing, this means that you must constantly envision the triangle. This leads to the most fruitful line of thought.
Is it an equilateral triangle?. I think the schedule should be on the hypotenuse and the thus it should be a right triangle... Isn't it?.
4. Don’t go dark.
Some features have long development lead times, months or even years. Yet slips usually happen a little bit every day, and must be compensated for a little every day. This means that the granularity of development tasks must be such that deliverables are achieved at intervals sufficiently small that slips can be compensated for. A week is a long time to go without knowing what is happening. While micromanaging is always a danger, and will certainly be an accusation leveled against you from time to time, if the goal of the project is to ship great software on time, and if everybody accepts that goal as uppermost, they generally enjoy the chase. Team interdependency is also a powerful motivational force.
Awesome.... I would repeat that keyword loudly..."Team interdependency is also a powerful motivational force".
5. Use zero defect (ZD) milestones.
Organize the project around the concept a reaching milestones with zero defects. Zero defects does not mean that the product does not have bugs, or missing functionality; it means that the product achieves the quality level that had been set for that milestone. The product is tested to that effect. The essential point of ZD milestones is that nobody makes the milestone until everybody does, and nobody leaves it until everybody does. This enables the team to discover what aspects of the project are in trouble. Load balancing can occur. Awareness of unknowns rises.
Ah...there you go "Discover the aspects leading to trouble your project, and ofcourse that is cured by awareness of unknowns..". Don't you think alike?..
6. Beware of a guy in a room.
This is really just a special case of "Don’t go dark." Specialist developers who lock themselves away in a room, going dark for long stretches, are anathema to shipping great software on time. Without regard to their individual brilliance, before investing a developer with a significant assignment, it is essential that they understand and agree with the type of development program you intend to run. They must be capable of performing on a team, making their work visible in modest increments and subjecting it to scrutiny as it matures. Some people find this intolerable, and though there is a role for people of this disposition in the software world, it is not as part of a team devoted to shipping great software on time.
But whether or not the cause is healthy or bogus, the results are uniformly fatal to the professional development organization. Beware. Extricating yourself from this trap is nearly impossible... believe it or not.....
7. Never trade a bad date for an equally bad date
Generally, you know you’re going to be late before you know when you’re going to be done. Further, everybody on the team and everybody they come in contact with knows you’re not going to hit the schedule. The pressure to reset the end-date (or the milestone date) is enormous. Even though your information is obviously better now than when you originally set your goal, it is probably insufficient to make a new schedule. This is because with each slip, you and your team are spending your credibility. It is essential that after a slip, the next milestone be hit. This is so the team believes in their ability to manage the project, and so that the reserves of credibility are rebuilt for later consumption.
Your near-in milestone should be extremely realistic, and uncertainties about later milestones will remain and should be highlighted. Let me know if you are coming late, so I can grab a cup of coffee from starbucks and can avoid waiting for you outside...
8. When slipping, don't fall.
Slipping is what happens when information that was unknown becomes less unknown. Though slipping is widely perceived to be a "bad" thing, it is the symptom of a good thing, as a fever is the sign of the body’s immune system at work. Although it is undesirable to have so many unknowns that slippage occurs, it is not an unusual situation, and may even be the norm. This is because much of contemporary software development is essentially experimental, i.e., new platforms, new operating systems, new programming technologies often coalesce on new programming projects to create a high degree of uncertainty.
Slips are also an opportunity to re-evaluate the feature content and resource loads, generally with an eye toward decreasing the features and shoring up weaker areas on the team.
A good slip should be a net positive. remember our right traingle becoming an obtuse one.. :)-
9. Low tech is good.
A smaller effort is almost always more desirable than a larger one. Shipping great software on time requires that we value an understood solution much higher than one fraught with unknowns. Keep in mind that customers would almost always rather see progress than promises.
I oppose this statement, fight against the deadline and you are not manufacturing the software, rather engineering it. So I think, you can make progress only when you promise something. Today we are living in a world where hard working has nothing to do with success, rather I call it "Smart Working". Infact I did send a mail to Honourable president of India, Dr A P J Abdul Kalam in late 2004 asking this, but I'm sad that he didn't reply to that. Anyway when you say you are working hard to succeed in life, make sure that you are following the smart and easiest way available at that time. I won't appreciate you using your fingers or a piece of paper and pencil to add 2345 and 4804, think smart and use calculator.
10. Design time at design time.
The product will ship when the design can be shown to be implemented. Developers and their managers often ignore the exigencies of time when creating a design. Instead, they should consider the implementation time as a critical design element. When evaluating alternative design decisions, the one that takes longer to implement is consuming more time and should therefore be disadvantaged in comparison to the alternative. This must always be weighed. Often, when appropriate design value is awarded to timeliness, implementation time can be substantially compressed.
A bad design can lead to a disaster. Always know the wall before you paint it. What is design patterns, does it solve the probelm...I can hear people asking pattern question like "what is Facade, Observer, Command, Decorator...blah blah blah...."?. Do they really know what it is?. I'm sorry for critizing few of the leaders I 've seen in my career. But today I'm also thinking of mastering all the behavioral, structural and creational patterns to criticize me better :)..
11. If you build it, it will ship.
Conversely, if you don't, it won't. The product should be built every day, along with all setup scripts and on-line help, in a public place, where QA can conduct appropriate assessment of daily status, and the entire team can observe progress or its lack. This is the single biggest indicator that a team is functional and a product being developed
As Bible says in Proverbs 18:21, we will eat the fruit of our tongues. Similarly what we do is what we ship...
12. Portability is for canoes.
And system software. Even discounting the added development burden, with the addition of each additional platform the job of QA increases substantially. While clever QA management can minimize the burden somewhat, the complexity of multi-platform support is beyond the reach of most development organizations. Place your bets. Demand multi-platform support from your system software vendor, then build your product on the absolute fewest number of platforms possible.
So bad that it is good...many times we loose many things without knowing what we are loosing... Jim should be more specific in product engineering practices as he was with business developement team at Microsoft.
Great Software
13. Enrapture the customers.
Most software is a renewal business. Customers buy multiple releases over a relatively long period of time. As a consequence, the market has a deep understanding of your software and its flaws, and your organization and its flaws. Often, the market has grown uncomfortably dependent on software that doesn't meet its needs. In many software situations, customers spend hours per/day uncomfortably shoe-horning their lives into your product. As a consequence, they crave your understanding, and will respond enthusiastically to the least sign of it. Normal success, meeting customer expectations, means to improve the most outrageous and flagrant violations of their needs from version to version. They will likely stay with you if you are faithful about that, though they may well be sullen if not mutinous.
Gaining this understanding and embodying it in your software requires skill, tenacity and creativity. You must recognize the central market need and organize all your technology and communications efforts in the direction of satisfying that need.
I love that word tenacity.....a Persistent determination towards delivering the requirements... Tell me, here what I want to know: What is the difference between a Software Engineer and an Obedient and well trained Dog [I have seen many of those excellent dogs in US :-)]. Both can do what they are asked to do. Comeon engineers, don't you think that this is the time to deliver something that is in the subconcious mind of our clients and not just delivering what our functional specification says.... :)-..I was kidding..we are smart..we can.. ..
14. Remember one thing: Unity.
Unity is the master principle of great software. Each element in the product is necessary to the value of the whole and all necessary elements are there. Since everything you need is there, you aren't tempted to go beyond the present experience, and since nothing is there that isn't required, your absorption into the world of the product will not be disturbed.
No arguements to Jim....I do beleive it is the time to conquer our individual goals to the success of the team. Remember that, ronaldinjo (soccer player of brazil ) who gave a minus pass to his teammate Emerson in a world cup, while ronaldinjo was very sure about placing the ball in to the goal post of germany. Good that Emerson did shoot the ball into germany's goal post over the shoulder of ronaldinjo... trust your collegue's ability...unity is strength..
15. State your theme.
Theme is the dominant idea that constitutes the basis of the design. All of the values of the product must stem from the theme. In order for people to comprehend the theme, it must be rendered with surpassing clarity. Theme is analogous to purpose. The more specific the purpose, the greater the effect. Having a theme to the product will require that you eliminate or at least minimize orthogonal values. This is painful and involves risk.
No comments....just state your theme...risk is always there in every steps, but mitigate it..
16. Vary it.
Variation is the theme restated and elaborated in slightly altered and embroidered ways. Variation is the means by which we intensify the user's comprehension and appreciation of our theme, and leverage his/her growing consciousness in new ways.
Leaders do not do different things, they do things differently.. (Shiv kera)
17. Balance it.
Allocate appropriate emphasis among the various elements of the product. If a key component supporting the theme, encountered every time the thematic function is enacted, is weak, the theme is weakly stated and the product will be justly criticized.
ahh...balance it and there is no secret to balance, you just have to feel the waves...
18. Evolve it.
Evolution is when earlier parts determine later parts. Lessons learned in one part of the product apply to the others. Things progress in a way that is pleasing. Outcomes, if not predictable, are satisfying because the product foreshadows them in countless ways.
Once born, nothing is predictable other than death. Softwares are not different. Once we kick off a project, the only thing we know is " We will deliver". But the question is "What you deliver and When you deliver?... Agile methodology helps project team to envision and engineer software through iterations and thus software evolves through sprints.
19. Your product should be a hierarchy.
Hierarchy is when the elements of the product gain attention in proportion to their importance. Closely related to the property of balance, hierarchy provides a means for establishing and evaluating balance. If the theme is the top of the hierarchy, elements at the next level have balanced value with respect to each other, all equally supporting the thematic function, and so on throughout the rest of the hierarchy.
Prioratize the tasks... a top down approach on a depth first hierarchy tree.
20. Establish a shared vision.
It seems absurd to even have to state this, yet it is perhaps the most difficult thing of all to achieve. Everybody on the team must know what they are trying to achieve, what the finished product will look like, what the basis of the product strategy is, and when they must deliver it in order for it to have its intended effect. Contradictory visions must be resolved and unified. Harmonious purpose must be achieved, or greatness is out of the question and even shipping becomes infinitely more complicated.
I'm excited to write it down here, shared vision comes on the top and is like a soccer team advancing towards the other team's goal post. We know what we are, we know what we can..but we don't know where we are...it is bad. Think this way, " if you know where you going, any road will help. If you don't know where you are, even the world map won't help you ". I use GPS to drive my car, but it is exceptional case. We are talking about a man lost in a desert..
Shipping
21. Get the team into ship mode.
There is a moment on every development project when it is ideal for a team to enter ship-mode. Ship mode is a high performance period characterized by efficiency and determination. It is a period of flow.
Shipmode is basically a succession of daily milestones climaxing with the product’s shipment. Change your mood, we are ready to ship our product. Lets talk about bugs now. :)
Let me conclude this article here. Now I want to sit back and think about all my comments in blue, othersie I will become a despondent.
Any comments or thoughts , please share here or mail me : jollson@hotmail.com
Let me put it this way, "Things which are not known are more at any stage of any software project, and that doesn't mean that we cannot deliver what our client wants. This is why today I see engineering as "Imagineering". Not sure what you think about that terminology, but tell me frankly, " What indicates success in your project development , progress or promises?".
Now have a look at Jim's 21 thumb rules and my thoughts are in blue color.
From Jim McCarthy, Microsoft Corporation:
Shipping great software on time is a difficult but not impossible task. Elements you think would count the most count for very little. Development methodology, process, technical prowess, excellence of tools and depth of project management skills all influence the outcome of a software development project; but nothing indicates success as much as the manager’s ability to focus on a few critical and conceptually simple things. These things can be expressed as rules of thumb.
Here I agree with Jim in the above statement, but I was wondering, wasn't that part of project management skills to identify those few critical and conceptually simple things?.
On Time
1. Don’t know what you don’t know.
It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you are things you pretended to understand but didn’t early on. At virtually every stage of even the most successful software projects, there are large numbers of very important things that are unknown. It is acceptable, even mandatory, to clearly articulate your ignorance, so that no one misunderstands the corporate state of unknowingness. If you do not disseminate this "lucid ignorance," disaster will surely befall you.
Human nature is such that we dislike not knowing things that are important to our well being. Since there is so much we don’t know in a software project, the nearly universal tendency among developers and their managers is to gloss over or even deny altogether the extent of their ignorance. You should reward and treasure those who consistently make themselves aware of the list of relevant things that are currently unknown. It requires mental and psychological strength to resist the normal human cravings for certainty and order. It especially difficult to believe in uncertainty when things have a veneer of orderliness, which is often the case. Pseudo-order is a maladapted defense against uncertainty.
Sometimes we must profess to know the things which are unknown at the time. But make sure that nobody else know it better before you manage to get to know the same. :)-
2. Get to a known state and stay there.
The function of QA is to know (and articulate) the quality of the product at all times in the development cycle. This should be achieved by abbreviated, repeatable tests conducted daily, and full product sweeps conducted weekly or biweekly.
It is not properly the job of QA to determine when a product is ready to ship; rather, the moment of shipworthiness in a product development cycle is evident to everyone involved, and is non controversial. This is because shipping has been the goal of the entire effort. Crossing the finish line, while it has intangible emotional and definite financial rewards, is no surprise when you’ve observed every single painful step toward it.
Agile methodologies serves this purpose upto some extend by making everything transparent. Having said that, what is this known state, is it a sprint backlog on which we all agreed upon after a scrum meeting?. I would rather call it a shared vision and corporate responsibilty to sail towards that deadline.
3. Remember the triangle.
There are only three things that you are working with as a development manager: resources (people and money), features and the schedule. Changing one has an impact on at least one other axis, usually two. It is a simple enough matter to mentally run through the sides of the triangle, or force others to do so, when discussing any part of it. Since the people, the product or the schedule is almost always what you’re discussing, this means that you must constantly envision the triangle. This leads to the most fruitful line of thought.
Is it an equilateral triangle?. I think the schedule should be on the hypotenuse and the thus it should be a right triangle... Isn't it?.
4. Don’t go dark.
Some features have long development lead times, months or even years. Yet slips usually happen a little bit every day, and must be compensated for a little every day. This means that the granularity of development tasks must be such that deliverables are achieved at intervals sufficiently small that slips can be compensated for. A week is a long time to go without knowing what is happening. While micromanaging is always a danger, and will certainly be an accusation leveled against you from time to time, if the goal of the project is to ship great software on time, and if everybody accepts that goal as uppermost, they generally enjoy the chase. Team interdependency is also a powerful motivational force.
Awesome.... I would repeat that keyword loudly..."Team interdependency is also a powerful motivational force".
5. Use zero defect (ZD) milestones.
Organize the project around the concept a reaching milestones with zero defects. Zero defects does not mean that the product does not have bugs, or missing functionality; it means that the product achieves the quality level that had been set for that milestone. The product is tested to that effect. The essential point of ZD milestones is that nobody makes the milestone until everybody does, and nobody leaves it until everybody does. This enables the team to discover what aspects of the project are in trouble. Load balancing can occur. Awareness of unknowns rises.
Ah...there you go "Discover the aspects leading to trouble your project, and ofcourse that is cured by awareness of unknowns..". Don't you think alike?..
6. Beware of a guy in a room.
This is really just a special case of "Don’t go dark." Specialist developers who lock themselves away in a room, going dark for long stretches, are anathema to shipping great software on time. Without regard to their individual brilliance, before investing a developer with a significant assignment, it is essential that they understand and agree with the type of development program you intend to run. They must be capable of performing on a team, making their work visible in modest increments and subjecting it to scrutiny as it matures. Some people find this intolerable, and though there is a role for people of this disposition in the software world, it is not as part of a team devoted to shipping great software on time.
But whether or not the cause is healthy or bogus, the results are uniformly fatal to the professional development organization. Beware. Extricating yourself from this trap is nearly impossible... believe it or not.....
7. Never trade a bad date for an equally bad date
Generally, you know you’re going to be late before you know when you’re going to be done. Further, everybody on the team and everybody they come in contact with knows you’re not going to hit the schedule. The pressure to reset the end-date (or the milestone date) is enormous. Even though your information is obviously better now than when you originally set your goal, it is probably insufficient to make a new schedule. This is because with each slip, you and your team are spending your credibility. It is essential that after a slip, the next milestone be hit. This is so the team believes in their ability to manage the project, and so that the reserves of credibility are rebuilt for later consumption.
Your near-in milestone should be extremely realistic, and uncertainties about later milestones will remain and should be highlighted. Let me know if you are coming late, so I can grab a cup of coffee from starbucks and can avoid waiting for you outside...
8. When slipping, don't fall.
Slipping is what happens when information that was unknown becomes less unknown. Though slipping is widely perceived to be a "bad" thing, it is the symptom of a good thing, as a fever is the sign of the body’s immune system at work. Although it is undesirable to have so many unknowns that slippage occurs, it is not an unusual situation, and may even be the norm. This is because much of contemporary software development is essentially experimental, i.e., new platforms, new operating systems, new programming technologies often coalesce on new programming projects to create a high degree of uncertainty.
Slips are also an opportunity to re-evaluate the feature content and resource loads, generally with an eye toward decreasing the features and shoring up weaker areas on the team.
A good slip should be a net positive. remember our right traingle becoming an obtuse one.. :)-
9. Low tech is good.
A smaller effort is almost always more desirable than a larger one. Shipping great software on time requires that we value an understood solution much higher than one fraught with unknowns. Keep in mind that customers would almost always rather see progress than promises.
I oppose this statement, fight against the deadline and you are not manufacturing the software, rather engineering it. So I think, you can make progress only when you promise something. Today we are living in a world where hard working has nothing to do with success, rather I call it "Smart Working". Infact I did send a mail to Honourable president of India, Dr A P J Abdul Kalam in late 2004 asking this, but I'm sad that he didn't reply to that. Anyway when you say you are working hard to succeed in life, make sure that you are following the smart and easiest way available at that time. I won't appreciate you using your fingers or a piece of paper and pencil to add 2345 and 4804, think smart and use calculator.
10. Design time at design time.
The product will ship when the design can be shown to be implemented. Developers and their managers often ignore the exigencies of time when creating a design. Instead, they should consider the implementation time as a critical design element. When evaluating alternative design decisions, the one that takes longer to implement is consuming more time and should therefore be disadvantaged in comparison to the alternative. This must always be weighed. Often, when appropriate design value is awarded to timeliness, implementation time can be substantially compressed.
A bad design can lead to a disaster. Always know the wall before you paint it. What is design patterns, does it solve the probelm...I can hear people asking pattern question like "what is Facade, Observer, Command, Decorator...blah blah blah...."?. Do they really know what it is?. I'm sorry for critizing few of the leaders I 've seen in my career. But today I'm also thinking of mastering all the behavioral, structural and creational patterns to criticize me better :)..
11. If you build it, it will ship.
Conversely, if you don't, it won't. The product should be built every day, along with all setup scripts and on-line help, in a public place, where QA can conduct appropriate assessment of daily status, and the entire team can observe progress or its lack. This is the single biggest indicator that a team is functional and a product being developed
As Bible says in Proverbs 18:21, we will eat the fruit of our tongues. Similarly what we do is what we ship...
12. Portability is for canoes.
And system software. Even discounting the added development burden, with the addition of each additional platform the job of QA increases substantially. While clever QA management can minimize the burden somewhat, the complexity of multi-platform support is beyond the reach of most development organizations. Place your bets. Demand multi-platform support from your system software vendor, then build your product on the absolute fewest number of platforms possible.
So bad that it is good...many times we loose many things without knowing what we are loosing... Jim should be more specific in product engineering practices as he was with business developement team at Microsoft.
Great Software
13. Enrapture the customers.
Most software is a renewal business. Customers buy multiple releases over a relatively long period of time. As a consequence, the market has a deep understanding of your software and its flaws, and your organization and its flaws. Often, the market has grown uncomfortably dependent on software that doesn't meet its needs. In many software situations, customers spend hours per/day uncomfortably shoe-horning their lives into your product. As a consequence, they crave your understanding, and will respond enthusiastically to the least sign of it. Normal success, meeting customer expectations, means to improve the most outrageous and flagrant violations of their needs from version to version. They will likely stay with you if you are faithful about that, though they may well be sullen if not mutinous.
Gaining this understanding and embodying it in your software requires skill, tenacity and creativity. You must recognize the central market need and organize all your technology and communications efforts in the direction of satisfying that need.
I love that word tenacity.....a Persistent determination towards delivering the requirements... Tell me, here what I want to know: What is the difference between a Software Engineer and an Obedient and well trained Dog [I have seen many of those excellent dogs in US :-)]. Both can do what they are asked to do. Comeon engineers, don't you think that this is the time to deliver something that is in the subconcious mind of our clients and not just delivering what our functional specification says.... :)-..I was kidding..we are smart..we can.. ..
14. Remember one thing: Unity.
Unity is the master principle of great software. Each element in the product is necessary to the value of the whole and all necessary elements are there. Since everything you need is there, you aren't tempted to go beyond the present experience, and since nothing is there that isn't required, your absorption into the world of the product will not be disturbed.
No arguements to Jim....I do beleive it is the time to conquer our individual goals to the success of the team. Remember that, ronaldinjo (soccer player of brazil ) who gave a minus pass to his teammate Emerson in a world cup, while ronaldinjo was very sure about placing the ball in to the goal post of germany. Good that Emerson did shoot the ball into germany's goal post over the shoulder of ronaldinjo... trust your collegue's ability...unity is strength..
15. State your theme.
Theme is the dominant idea that constitutes the basis of the design. All of the values of the product must stem from the theme. In order for people to comprehend the theme, it must be rendered with surpassing clarity. Theme is analogous to purpose. The more specific the purpose, the greater the effect. Having a theme to the product will require that you eliminate or at least minimize orthogonal values. This is painful and involves risk.
No comments....just state your theme...risk is always there in every steps, but mitigate it..
16. Vary it.
Variation is the theme restated and elaborated in slightly altered and embroidered ways. Variation is the means by which we intensify the user's comprehension and appreciation of our theme, and leverage his/her growing consciousness in new ways.
Leaders do not do different things, they do things differently.. (Shiv kera)
17. Balance it.
Allocate appropriate emphasis among the various elements of the product. If a key component supporting the theme, encountered every time the thematic function is enacted, is weak, the theme is weakly stated and the product will be justly criticized.
ahh...balance it and there is no secret to balance, you just have to feel the waves...
18. Evolve it.
Evolution is when earlier parts determine later parts. Lessons learned in one part of the product apply to the others. Things progress in a way that is pleasing. Outcomes, if not predictable, are satisfying because the product foreshadows them in countless ways.
Once born, nothing is predictable other than death. Softwares are not different. Once we kick off a project, the only thing we know is " We will deliver". But the question is "What you deliver and When you deliver?... Agile methodology helps project team to envision and engineer software through iterations and thus software evolves through sprints.
19. Your product should be a hierarchy.
Hierarchy is when the elements of the product gain attention in proportion to their importance. Closely related to the property of balance, hierarchy provides a means for establishing and evaluating balance. If the theme is the top of the hierarchy, elements at the next level have balanced value with respect to each other, all equally supporting the thematic function, and so on throughout the rest of the hierarchy.
Prioratize the tasks... a top down approach on a depth first hierarchy tree.
20. Establish a shared vision.
It seems absurd to even have to state this, yet it is perhaps the most difficult thing of all to achieve. Everybody on the team must know what they are trying to achieve, what the finished product will look like, what the basis of the product strategy is, and when they must deliver it in order for it to have its intended effect. Contradictory visions must be resolved and unified. Harmonious purpose must be achieved, or greatness is out of the question and even shipping becomes infinitely more complicated.
I'm excited to write it down here, shared vision comes on the top and is like a soccer team advancing towards the other team's goal post. We know what we are, we know what we can..but we don't know where we are...it is bad. Think this way, " if you know where you going, any road will help. If you don't know where you are, even the world map won't help you ". I use GPS to drive my car, but it is exceptional case. We are talking about a man lost in a desert..
Shipping
21. Get the team into ship mode.
There is a moment on every development project when it is ideal for a team to enter ship-mode. Ship mode is a high performance period characterized by efficiency and determination. It is a period of flow.
Shipmode is basically a succession of daily milestones climaxing with the product’s shipment. Change your mood, we are ready to ship our product. Lets talk about bugs now. :)
Let me conclude this article here. Now I want to sit back and think about all my comments in blue, othersie I will become a despondent.
Any comments or thoughts , please share here or mail me : jollson@hotmail.com
|
|
