Wednesday, April 22, 2015
Friday, December 6, 2013
Sunday, December 11, 2011
Sunday, November 8, 2009
SWOT Analysis On Agile Methods
SWOT is an acronym of strength, weaknesses, opportunities and threats. The main intention of this analysis is to specify the organization’s internal and external factors that are favorable or unfavorable for companies to achieve particular business objective. Strength and weaknesses are included within the internal factors, while opportunities and threats are part of external factors.
1. Strengths
Aligned with the business
There is evident alignment between agile development and business. The basic idea of these methods is that only business features that bring more value can be built, making these methods to be completely business-driven. This is because these methods are:
- providing flexibility – fast response to customer requirements
- faster – providing the highest return on investment
- cheaper – early delivery can lead to less time spent in development
High visibility of process
Agile principles allow the stakeholders to participate throughout the development process and project progress to give requirements and provide feedback. Business people and developers work together daily throughout the project (Cockburn, 2002).
This keeps the stakeholder updated in every stage of the process and provides visibility for the project’s progress.
Flexibility to change
In every iteration, change can be accepted and expected in agile methods. Agile welcomes changing requirements, even late in development. Agile process harness change for the customer’s competitive advantage (Cockburn, 2002). As the process of development is underway, requirements can emerge by the stakeholders who are actively involved in the process.
Reduced time to market
Agile techniques are incremental and can deliver the business value early, cost or revenue savings can be figured out sooner and the highest return on investment is provided.
Early delivery is also mentioned in one of the Agile Manifesto principles: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale (Cockburn, 2002).
Cost control
Agile uses time-boxing to control schedule and is encouraging the customer to prioritize all product functionalities that will be delivered. Using such a fixed timescale enables a fixed budget. Due to the evolutionary and iterative nature that agile techniques have, wasteful overheads, mistakes in requirements or architecture can be corrected in time without affecting the predetermined budget.
Risk management
The visibility in agile development helps to discover early any possible issue which might contain a potential risk. If this occurs, any required decision can be taken as soon as possible to mitigate that risk. Further, these risky items are considered as top –priority for the team, unless they are solved.
2. Weaknesses
Intensive customer commitment needed
One of the basic principles of agile development is to have continuous collaboration with the customer in order to deliver the demanded product. As the principle of active user involvement and close collaboration is highly recommended in agile environment, it requires very intensive commitment and concentration by the user throughout the development process. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation (Cockburn, 2002).
Constant need for testers
Testing is an integral part of agile projects helping to ensure the quality and the correctness throughout the project. The incremental nature of these methods implies that after completion of every iteration, the product must go through testing procedure before it can reach the market. For the tester, the most important things to note about Scrum are its iterative lifecycle
and frequent communication (Kohl, 2005). This requires the involvement of testers after each sprint or iteration. Even though testers are crucial during the project lifecycle, their involvement for every sprint will increase the cost of resources significantly.
Not suitable for offshore outsourcing
I already elaborated that agile methods work perfectly with collocated teams because the stakeholders are local and available for participation providing feedback at real time. Taking into account that fact, many questions can arise: What if we do not have face-to-face communication and teams are spread out between multiple locations with different cultural backgrounds. How agile techniques can help to mitigate the challenges of off-shored/distributed projects? Will the reaction for change be fast enough? (Ambler, 2003) believes that adopting agile techniques will be troublesome and taxing for offshore outsources due to cultural and communication barriers.
Even though teams can rely on recent technological tools for online communication such as videoconferences, VoIP4, or wikis5; the issue of security remains as a potential threat to this communications.
3. Opportunities
Team empowerment
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done (Cockburn, 2002). The teams need to receive continuous support, trust and empowerment to make decisions about how to respond to change and how to build the best architectures and designs. All the requirements must be collected and refined or prioritized by the whole team, and make collective decisions and agreements about the tasks that have to be delivered.
Revolutionize the business
Using agile approach, the team learns more about the customer side and can better develop software that meets the business needs. Recently, agile methods are becoming trendy and application development teams are increasingly following these methods.
4. Threats
Security and quality of communication when outsourcing
Communication is the key issue in development. Development is a lot easier when the teams are collocated and the IT and the business individuals are located in one location. For projects that are spread in multiple locations or are outsourced, this communication becomes more complex. The teams will face difficulties to track and monitor the development activities and to adapt to business needs and circumstances. Therefore, teams should use tools for online collaborations. When using these technologies for communication such as VOIP, videoconferences, teams must take into consideration many factors concerning the quality, reliability, security and safety of this type of communications. All these factors, if not managed properly can lead to lack of visibility of project progress, feedback delay, and reduced communication bandwidth.
1. Strengths
Aligned with the business
There is evident alignment between agile development and business. The basic idea of these methods is that only business features that bring more value can be built, making these methods to be completely business-driven. This is because these methods are:
- providing flexibility – fast response to customer requirements
- faster – providing the highest return on investment
- cheaper – early delivery can lead to less time spent in development
High visibility of process
Agile principles allow the stakeholders to participate throughout the development process and project progress to give requirements and provide feedback. Business people and developers work together daily throughout the project (Cockburn, 2002).
This keeps the stakeholder updated in every stage of the process and provides visibility for the project’s progress.
Flexibility to change
In every iteration, change can be accepted and expected in agile methods. Agile welcomes changing requirements, even late in development. Agile process harness change for the customer’s competitive advantage (Cockburn, 2002). As the process of development is underway, requirements can emerge by the stakeholders who are actively involved in the process.
Reduced time to market
Agile techniques are incremental and can deliver the business value early, cost or revenue savings can be figured out sooner and the highest return on investment is provided.
Early delivery is also mentioned in one of the Agile Manifesto principles: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale (Cockburn, 2002).
Cost control
Agile uses time-boxing to control schedule and is encouraging the customer to prioritize all product functionalities that will be delivered. Using such a fixed timescale enables a fixed budget. Due to the evolutionary and iterative nature that agile techniques have, wasteful overheads, mistakes in requirements or architecture can be corrected in time without affecting the predetermined budget.
Risk management
The visibility in agile development helps to discover early any possible issue which might contain a potential risk. If this occurs, any required decision can be taken as soon as possible to mitigate that risk. Further, these risky items are considered as top –priority for the team, unless they are solved.
2. Weaknesses
Intensive customer commitment needed
One of the basic principles of agile development is to have continuous collaboration with the customer in order to deliver the demanded product. As the principle of active user involvement and close collaboration is highly recommended in agile environment, it requires very intensive commitment and concentration by the user throughout the development process. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation (Cockburn, 2002).
Constant need for testers
Testing is an integral part of agile projects helping to ensure the quality and the correctness throughout the project. The incremental nature of these methods implies that after completion of every iteration, the product must go through testing procedure before it can reach the market. For the tester, the most important things to note about Scrum are its iterative lifecycle
and frequent communication (Kohl, 2005). This requires the involvement of testers after each sprint or iteration. Even though testers are crucial during the project lifecycle, their involvement for every sprint will increase the cost of resources significantly.
Not suitable for offshore outsourcing
I already elaborated that agile methods work perfectly with collocated teams because the stakeholders are local and available for participation providing feedback at real time. Taking into account that fact, many questions can arise: What if we do not have face-to-face communication and teams are spread out between multiple locations with different cultural backgrounds. How agile techniques can help to mitigate the challenges of off-shored/distributed projects? Will the reaction for change be fast enough? (Ambler, 2003) believes that adopting agile techniques will be troublesome and taxing for offshore outsources due to cultural and communication barriers.
Even though teams can rely on recent technological tools for online communication such as videoconferences, VoIP4, or wikis5; the issue of security remains as a potential threat to this communications.
3. Opportunities
Team empowerment
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done (Cockburn, 2002). The teams need to receive continuous support, trust and empowerment to make decisions about how to respond to change and how to build the best architectures and designs. All the requirements must be collected and refined or prioritized by the whole team, and make collective decisions and agreements about the tasks that have to be delivered.
Revolutionize the business
Using agile approach, the team learns more about the customer side and can better develop software that meets the business needs. Recently, agile methods are becoming trendy and application development teams are increasingly following these methods.
4. Threats
Security and quality of communication when outsourcing
Communication is the key issue in development. Development is a lot easier when the teams are collocated and the IT and the business individuals are located in one location. For projects that are spread in multiple locations or are outsourced, this communication becomes more complex. The teams will face difficulties to track and monitor the development activities and to adapt to business needs and circumstances. Therefore, teams should use tools for online collaborations. When using these technologies for communication such as VOIP, videoconferences, teams must take into consideration many factors concerning the quality, reliability, security and safety of this type of communications. All these factors, if not managed properly can lead to lack of visibility of project progress, feedback delay, and reduced communication bandwidth.
Saturday, August 22, 2009
Agile methods versus risk mitigation
Every project as well as software projects are followed by uncertainties and are subject to risk. Agile development methods are business driven and risk driven. Because agile methods are incremental, this project risk should be the main concern of the team when choosing how to deal with high risk areas and how to proceed with the process without loosing time, money and market share.
Though many books for project management offer several practices on dealing with risk in a certain projects and environments, most of these practices are very far from agile.
So, the dilemma that arises here is: how to adapt these traditional risk management approaches meant for different projects into agile iterations that can last seven to 30 days?
Crafting a mitigation involves understanding the root cause of the risk, brainstorming potential ways to prevent the risk, and then breaking them down into WBS (Work Breakdown Structure) elements and individual tasks that can be added to the detailed project plan.
Taking into account the incremental nature of agile methods, they can identify risks in the current iteration and find solutions to mitigate them in the upcoming iteration. Therefore, agile can identify and recognize risks before they can influence the project.
One of the challenges that developers and management may face in mitigating the risk is as follows: what if the items with low priority, which are not prioritized by the business, can contain risk.
Considering the priorities assigned by the stakeholders, the team selects the items with higher priority in the Product Backlog. But, if the remaining items contain any risk, then those items has to be moved up the stack of prioritized feature list and to be processed as soon as possible, as illustrated in Figure below.
Though many books for project management offer several practices on dealing with risk in a certain projects and environments, most of these practices are very far from agile.
So, the dilemma that arises here is: how to adapt these traditional risk management approaches meant for different projects into agile iterations that can last seven to 30 days?
Crafting a mitigation involves understanding the root cause of the risk, brainstorming potential ways to prevent the risk, and then breaking them down into WBS (Work Breakdown Structure) elements and individual tasks that can be added to the detailed project plan.
Taking into account the incremental nature of agile methods, they can identify risks in the current iteration and find solutions to mitigate them in the upcoming iteration. Therefore, agile can identify and recognize risks before they can influence the project.
One of the challenges that developers and management may face in mitigating the risk is as follows: what if the items with low priority, which are not prioritized by the business, can contain risk.
Considering the priorities assigned by the stakeholders, the team selects the items with higher priority in the Product Backlog. But, if the remaining items contain any risk, then those items has to be moved up the stack of prioritized feature list and to be processed as soon as possible, as illustrated in Figure below.
This can help teams to balance the risk and the business requirements. Despite the occurrence of not prioritized risk items in Product Backlog, the business side remains actively involved throughout the development process.
Sunday, May 3, 2009
Scrum Roles
Scrum as a framework has three roles: Product Owner, Scrum Master, and Team. The people who fill these roles are those who have committed to the project. Others might be interested in the project, but they aren’t on the hook. Scrum makes a clear distinction between these two groups and ensures that those who are responsible for the project have the authority to do what is necessary for its success and that those who aren’t responsible can’t interfere unnecessarily. (Ken Schwaber, 2004).
The Product Owner
The product owner is accountable for achieving maximum business value by collecting the overall requirements from the customers, as well as stakeholders and team members.
This role is equivalent to the customer role in the Agile Manifesto. The Product Owner defines the characteristics of the product, decides on launch date and content, return of investment (ROI) as well as creating and prioritizing the list of wanted requirements. This list is called the product backlog and is described further below.
The Scrum Master
The Scrum Master is one of the most important elements of Scrum. He doesn’t have the role of project manager; he is leading and helping the team with tasks which don't include development. The Scrum master is not controlling the team but only is guiding it.
The Scrum master is responsible for establishing scrum practices and rules, representing management to the project, shielding the team and removing obstacles—making sure, among the other things, that each team-member has proper hardware and software resources, desk space, etc. (Asproni, 2006).
The Scrum Master makes sure that the Scrum practices are understood and followed by everyone on the team (as well as those in management), and resolves those issues that the organizations find difficult to succeed. These misconceptions can occur inside the team, against the management, customer or lack of knowledge in the team.
The Team
The team is responsible for developing activities requested by the customer. The team is cross-functional – including all the resources and expertise to deliver the product each sprint - and self-managing, with broad autonomy inside the team. The team can determine who will do what and how to continue with the delivery without external interference. The size of the team is five to ten people.
The Product Owner
The product owner is accountable for achieving maximum business value by collecting the overall requirements from the customers, as well as stakeholders and team members.
This role is equivalent to the customer role in the Agile Manifesto. The Product Owner defines the characteristics of the product, decides on launch date and content, return of investment (ROI) as well as creating and prioritizing the list of wanted requirements. This list is called the product backlog and is described further below.
The Scrum Master
The Scrum Master is one of the most important elements of Scrum. He doesn’t have the role of project manager; he is leading and helping the team with tasks which don't include development. The Scrum master is not controlling the team but only is guiding it.
The Scrum master is responsible for establishing scrum practices and rules, representing management to the project, shielding the team and removing obstacles—making sure, among the other things, that each team-member has proper hardware and software resources, desk space, etc. (Asproni, 2006).
The Scrum Master makes sure that the Scrum practices are understood and followed by everyone on the team (as well as those in management), and resolves those issues that the organizations find difficult to succeed. These misconceptions can occur inside the team, against the management, customer or lack of knowledge in the team.
The Team
The team is responsible for developing activities requested by the customer. The team is cross-functional – including all the resources and expertise to deliver the product each sprint - and self-managing, with broad autonomy inside the team. The team can determine who will do what and how to continue with the delivery without external interference. The size of the team is five to ten people.
Monday, April 20, 2009
Overview of Scrum philosophy
One of the most popular agile methods is Scrum. It's one of the main working framework used by hundreds of companies among which Microsoft, Yahoo!, and Google.
Scrum as iterative development method has been developed in the 80’s and 90’s. According to (Takeuchi and Nonaka, 1986), projects using small, cross-functional teams historically produce the best results. These teams are like the Scrum formation in Rugby. Scrum has been practiced mostly by Manifesto authors Ken Schwaber, Jeff Sutterland and Mike Beedle. Scrum as a management process for managing product development is not used just in software development, but can be adapted for use for different types of projects.
According to Ken Schwaber, Scrum is used for complex work in which it is impossible to predict everything that will occur. Accordingly, Scrum simply offers a framework and set of practices that keep everything visible. This allows Scrum’s keep the project moving toward the desired goals. Scrum helps in making things transparent by encouraging communication, embracing change and improving productivity. In order to work as Scrum suggests, the entire team must posses solid knowledge in analysis design, implementation, testing and documentation.
The primary goal of Scrum is to organize teams and deliver software that provides the highest business value. It concentrates on prioritizing work based on business value, amending the beneficiary of what is delivered, and enhancing revenue. Scrum as a process is incremental. Each increment is called sprint, where each sprint lasts for four weeks. Prior to the sprint, there is a sprint planning meeting where the user determines what features should be developed and followed in the next sprint. During the sprint, the team meets daily at the same time at a short meeting called a scrum or the daily stand-up meeting. Each team member answers three questions:
1. What did I do since the last Scrum meeting?
2. What do I plan on doing between now and the next Scrum meeting?
3. Do I have any obstacle?
After each sprint, a sprint review meeting is organized, where the team presents what they developed and the customer gets to see what was achieved during the sprint. Sometimes, a sprint retrospective meeting can be held, where they analyze the process and try to find out what went wrong and what can be improved until the best solution is found. Together, the Sprint planning meeting, the Daily Scrum, the Sprint review, and the Sprint retrospective constitute the empirical inspection and adaptation practices of Scrum. Schwaber uses the figure below to visualize all steps defined in Scrum.
Nowadays, many cutting edge and leading Silicon Valley companies are practicing Scrum method in applications development to reduce the time to the market and providing a stable platform for the web that should be able to take in new functionalities with as little changes as possible.
Scrum as iterative development method has been developed in the 80’s and 90’s. According to (Takeuchi and Nonaka, 1986), projects using small, cross-functional teams historically produce the best results. These teams are like the Scrum formation in Rugby. Scrum has been practiced mostly by Manifesto authors Ken Schwaber, Jeff Sutterland and Mike Beedle. Scrum as a management process for managing product development is not used just in software development, but can be adapted for use for different types of projects.
According to Ken Schwaber, Scrum is used for complex work in which it is impossible to predict everything that will occur. Accordingly, Scrum simply offers a framework and set of practices that keep everything visible. This allows Scrum’s keep the project moving toward the desired goals. Scrum helps in making things transparent by encouraging communication, embracing change and improving productivity. In order to work as Scrum suggests, the entire team must posses solid knowledge in analysis design, implementation, testing and documentation.
The primary goal of Scrum is to organize teams and deliver software that provides the highest business value. It concentrates on prioritizing work based on business value, amending the beneficiary of what is delivered, and enhancing revenue. Scrum as a process is incremental. Each increment is called sprint, where each sprint lasts for four weeks. Prior to the sprint, there is a sprint planning meeting where the user determines what features should be developed and followed in the next sprint. During the sprint, the team meets daily at the same time at a short meeting called a scrum or the daily stand-up meeting. Each team member answers three questions:
1. What did I do since the last Scrum meeting?
2. What do I plan on doing between now and the next Scrum meeting?
3. Do I have any obstacle?
After each sprint, a sprint review meeting is organized, where the team presents what they developed and the customer gets to see what was achieved during the sprint. Sometimes, a sprint retrospective meeting can be held, where they analyze the process and try to find out what went wrong and what can be improved until the best solution is found. Together, the Sprint planning meeting, the Daily Scrum, the Sprint review, and the Sprint retrospective constitute the empirical inspection and adaptation practices of Scrum. Schwaber uses the figure below to visualize all steps defined in Scrum.
Nowadays, many cutting edge and leading Silicon Valley companies are practicing Scrum method in applications development to reduce the time to the market and providing a stable platform for the web that should be able to take in new functionalities with as little changes as possible.
Subscribe to:
Posts (Atom)