When to use Agile/Scrum

Transcription

1 When to use Agile/Scrum A Common Sense Model to Determining When or If You Should Leverage an Agile Scrum Methodology Depending on Your Project, Resources and Company. By Rick Rene Managing Director of Consulting Note: This White Paper assumes the reader already has a basic knowledge of Agile and Scrum.

2 The Agile Landscape Today Agile and Scrum are hot concepts today and many advocates feel this is the only way to go. Many case studies are emerging showing the true value of iterative development, even with large complex programs that may have numerous interdependent projects. But does this mean that Agile and Scrum is a no brainer for your organization? And even if you have had some successful projects, does that mean that all types of projects should use Agile moving forward? Also, can distributed and offshore resources be leveraged for Agile projects? Common Sense Framework To give these attributes a framework of common sense, we will look into 3 frequently used Software Development Life Cycle (SDLC) methods that we see within the IT world today. T hen we will dive into the characteristics of the above 3 attributes (project, resources and company) to help determine which SDLC will most likely be successful. The 3 SDLCs we will discuss include: Agile using Scrum (Co-Located) Agile using Scrum (Distributed) Sequential Development (Waterfall) Should Agile be used by all companies for all types of projects? Can distributed and offshore resources be leveraged for Agile projects? Agile is Not Always Suitable Agile and Scrum is not suited for all projects. You need to look at the characteristics of the project, the resources and the company before deciding to move down the Agile Scrum path. Some Agile purists would disagree, but common sense can prevail if you use a model that looks holistically at these three main attributes: Project Attributes Resource Attributes Company Attributes Moving down the Agile path before analyzing these attributes can lead to frustration when Agile projects go astray. Many other Agile or iterative development methods exist besides Scrum (XP, FDD, UP, Lean, DSDM, etc.) However, Scrum has become the most popular and most successfully implemented, largely because of its simplicity. All of these Agile methods focus on prioritization of features/ user stories by business value and working in short fixed time frames/sprints where each iteration produces working software. With Scrum, co-located teams are recommended for maximum productivity. However, new techniques and tools are available that are now allowing distributed teams, even with offshore resources, to be effective with Scrum. The Waterfall Sequential SDLC dominated best practice thinking until the iterative movement took hold over the last decade. Many flavors of Waterfall also exist, but nearly all have an emphasis on comprehensive documentation, sign-offs and heavy project management. 1

3 Common Sense Framework (continued) Descriptions of each of the SDLC we will use for this model are provided in the matrix below: Based on the above definitions, we will now determine when to use each of these development methodologies based upon the project, resources and company attributes. When To Use Agile Using Scrum (Co-located) Co-located Agile often produces the best results of reliable working software in short timeframes (usually 2-4 weeks). Co-location allows for daily stand-ups, improved communication and teamwork. Use Co-located Scrum when the characteristics of the Project include: High Profile Project. Success is an imperative so you need continual feedback from the business. You are also more likely to get a strong full-time dedicated Product Owner from the business which is critical to the success of Scrum. Newer Technology. When working with new technology, surprises will happen and adjustments will need to be made. Short sprints allow these problems to surface early which is important to success with newer technologies. Innovative Process. When IT is working with the business on an innovative process, the business needs to be part of the team since there is likely very little tribal knowledge or proven out detail processes. A Scrum Product Owner is more vital than ever when rolling out innovative processes. Requirements Flexibility Needed. If requirements are likely to change for any reason, Agile will be much more productive than Waterfall as only a small number of high value features are developed each Sprint. If there is any directional uncertainty, an Agile approach can help create progress and momentum while providing for flexibility to change directions as competitive, regulatory or environmental needs become clear. Quick Time to Market Needed. Only developing the highest priority features and having working software in each sprint results in a better chance of eliminating non-vital features. In addition, co-located teams almost always have shorter ramp-up times. 2

4 When To Use Agile Using Scrum (Co-located) (continued) Use Co-located Scrum when the characteristics of Resources include: Dedicated Full-Time Team Members that are Cross-Functional. Scrum needs to have full-time dedicated resources that are cross functional (developers, testers, etc.). The ideal team size of 5-7 dedicated team members with a dedicated Scrum Master and Product Owner from the business. Ability to Co-locate. Often co-location can be accomplished through the use of local resources as well as augmenting the team with Agile experienced contractors or consulting resources. This can include resources that travel weekly to the team site. When the scale of a project increases, often talent from multiple locations needs to be leveraged and colocation may not be an option. Team Sizes Between 2-10 Members. Dedicated, co-located, cross functional teams of the correct team size will perform best with Scrum. Projects that are too small to be cross-functional with dedicated development resources often are not good candidates for Agile. Large complex projects can also be a challenge for Scrum, especially if a significant number of developers are needed. A Scrum of Scrum concept can help scale larger projects with multiple Scrum teams, however, each team ideally needs to have a the majority of the team located with the Product Owner and the business stakeholders. Use Co-located Scrum when the characteristics of the Company include: Collaborative Culture. A business that is less command and control and encourages teamwork within and between the business and IT. Business that is IT Savvy. A business that needs to be in charge of all critical IT projects. Every critical project needs one business Product Owner and to allow scope to be flexible for each sprint. Contracting with IT and vendors is based upon timeframes and prioritized workable code, not based upon scope. Co-location allows for daily stand-ups, improved communication and teamwork When to use Agile Using Scrum (Distributed) Distributed Scrum is more difficult to execute than Co-located Scrum as a co-located team will almost always outperform a distributed team. However, when it s infeasible to co-locate talented team members, distributed agile often is the best choice. Distributed teams significantly increase communication challenges. You will need well defined and followed processes, distance communication tools and documented methodology on how all of the parts work together to allow Scrum to work. Example tools include unified communication tools (video or web conferencing) and Agile development software (Rally Dev, Version One, etc.). With distributed teams running a Sprint Zero and the first few Sprints on a co-located basis, can be very helpful. Also, having empowered Scrum Masters and Product Owners offshore can often create selffunctioning teams offshore. Use Distributed Scrum when the characteristics of the Project include: Same as Co-Located Agile (see above for detail). High Profile, Newer Technology, Innovative Process, and Requirements Flexibility Needed. Ramp Up Time is Available. For new teams, ramp up time will be longer than co-located teams or established Waterfall teams. However, ramp-up time is often worth the investment when Agile productivity is realized. In addition, early co-location of the teams can shorten this ramp up time. 3

5 When to use Agile using Scrum (Distributed) (continued) Use Distributed Scrum when the characteristics of Resources include: Dedicated Full-time Team Members that are Cross-functional. Same as Co-Located Agile (see above for detail). Inability to Co-locate. Often co-location cannot be easily accomplished (space, budget, etc.) and the talent on either or both IT and the business is naturally distributed. Larger Team Sizes Needed. Projects that are complex and need a large amount of resources often cannot be co-located. If many of the characteristics point to agile, Scrum can be successful, even with offshore resources. Processes and Tools discussed above need to be leveraged and a Scrum of Scrums concept should be considered. Use Distributed Scrum when the characteristics of the Company include: Use Distributed Scrum when the characteristics of Collaborative Culture. Same as Co-located Agile the Company include: (see above for detail). Collaborative Culture. Same as Co-located Agile Business that is IT Savvy. Same as Co-located Agile (see above for detail). (see above for detail). Business that is IT Savvy. Same as Co-located Agile (see above for detail). When it s feasible to co-locate When it s feasible to co-locate talented talented team members, distributed Agile team members, often distributed is the best Agile choice often is the best choice When to use Sequential Development (Waterfall) When actively managed with proper procedures and the right talent, waterfall development can work quite well. However, failure often happens because the characteristics of the project, resources and company are better suited for agile. Use Waterfall/Sequential Development when the characteristics of the Project include: Non-High Profile Project. Not all projects are high profile and can benefit from the rigor of the waterfall methods. Stable Technology. Waterfall is best suited for stable technologies. Significant project delays can occur if a technology surprise happens late in the process. No Major Process Innovation. Many projects don t require major process innovation and therefore, the risk is low of process changes happening midstream. Requirements are Stable. Best suited for welldefined projects with fewer tendencies to change during the project timeline. Quick Time to Market not Needed. It s important for IT to work with the business to prioritize projects against each other to assure projects without a true time to market need are identified. These projects can often be completed with non-dedicated teams which are never recommended with Scrum. Well established waterfall teams often have little ramp up time and thus are often less risky than newly established distributed agile teams. 4

6 When to use Sequential Development (Waterfall) (continued) Use Waterfall/Sequential Development when the characteristics of Resources include: Inability to Co-locate. Often co-location cannot be easily accomplished (space, budget, etc.) and the IT and business talent is naturally distributed. Low Cost Talent Available. Less expensive resources with less experience are available (i.e. offshore). Strong documentation is imperative for these projects, so waterfall is often the best fit. Team Size Varies. Scrum works best with teams from 2-10 developers. If the project only needs a few resources or very large teams that are distributed, often waterfall will be a better fit. For very large programs, Agile requires your company to be very mature and disciplined in agile methodology. The Agile Scrum of Scrums has shown much success in delivering large scale projects, but it requires significant experience and success with agile. Use Waterfall/Sequential Development when the characteristics of the Company include: Command and Control Company Culture. Agile is very collaborative and does not work well with dictator type project management. The rigor of Waterfall may be necessary in these cultures. Contracts Require Full Scope and Documentation. Often when working with contracts, flexible scope is not an option. Flexible scope is an absolute necessity of Scrum, so contracts need to written with that in mind. Otherwise, Waterfall may be a better fit, especially if the contract also requires heavy documentation. When actively managed with proper procedures and the right talent, waterfall development can work quite well Companies Can Leverage All Three Methods Many MATRIX clients leverage a combination of the Companies Can Leverage All Three above methodologies by using much of the common Methods sense discussed above. High-profile, quick time-tomarket projects utilize the co-located Scrum Many MATRIX clients leverage a combination of the methodology where we can create value very quickly above methodologies by using much of the common with local teams. For maintenance and other noncritical projects, a waterfall type methodology is sense discussed above. High-profile, quick time-tomarket projects utilize the co-located Scrum utilized. methodology where we can create value very quickly with Some local clients teams. actually For maintenance leverage all and 3 of other above noncritical methodologies. projects, a Larger waterfall initiatives type methodology that are time- is tomarket sensitive utilize distributed Scrum with utilized. offshore resources empowered with offshore Some clients actually leverage all 3 of the above Product Owners and Scrum Masters. Maintenance methodologies. Larger initiatives that are time- tomarket sensitive utilize distributed Scrum with projects use less expensive and less experienced resources leveraging Waterfall. However, several offshore resources empowered with offshore smaller, but time-to-market sensitive projects are Product Owners and Scrum Masters. Maintenance now using onshore, co-located Scrum. projects use less expensive and less experienced resources Designate leveraging from Waterfall. the beginning However, several of the smaller, project but time-to-market what methodology sensitive projects you will are now using onshore, co-located Scrum. leverage and adhere to the methodology principles with rigor Designate from the beginning of the project what methodology you will leverage designate from and the adhere beginning to the of the methodology project what methodology you will leverage and adhere to the principles with rigor The key to improving project success is to assure you methodology principles with rigor and assure you The have key the to proper improving resources project dedicated. success is to If Agile assure is you going designate to be a bigger from the part beginning of you company s of the project future, what it s methodology often best to you create will hybrid leverage teams and adhere of highly to the methodology experienced principles resources with combined rigor and with assure less you have experienced the proper resources. resources Also, dedicated. having the If Agile less is going to experienced be a bigger part resources, of you shadow company s experienced future, it s often resources best to can create allow hybrid you to teams replicate of highly teams with experienced greater success resources on later combined projects. with less experienced resources. Also, having the less experienced resources, shadow experienced resources can allow you to replicate teams with greater success on later projects. 5

7 No Mini-Waterfall or Scrumbut I see many clients struggle with Scrum and the causes of these struggles almost always come down to the lack of adherence to Scrum principles. When only a few of the principles are followed, the methodology often becomes a mini-waterfall or WaterScrum which is doomed to failure from the start. Others call it Scrumbut meaning We use Scrum, but we don t. Success with Scrum requires no deviation from the basic principles. Some key Scrum principles include: One dedicated Product Owner (decision maker) from the business as part of the team who meets daily with the team. Dedicated full-time resources that are crossfunctional (QA included!). Each Sprint s scope needs to be flexible within a fixed timeframe and workable code developed for every Sprint. The Sprint deadline is sacred and does not change. A working software demo is given to the business stakeholders for every Sprint. Sprint Retrospectives are completed for every Sprint.. User Stories are prioritized by business value before every Sprint. User stories with serious defects are not considered done and incomplete stories are reprioritized into the user backlog during Sprint Planning. Additional success factors could be discussed, but I find nearly everyone who is struggling with Agile is not adhering to one or more of the above basic Scrum principles. So be sure to pick your methodology for each project from the beginning and then fully live up to the methodology s key principles. Otherwise, you may be using Scrumbut and the desired results will not be met. About the Author: Rick Rene Rick Rene is the Managing Director of Consulting for WaveCreste. Rick helps clients create IT value through services including Agile education and adoption. He helps deliver Agile LunchNLearn sessions for leads training development for Agile and Application Development. Prior to joining WaveCreste, Rick was a Partner with Accenture for the High Tech and Communications market unit and led an IT Department of over 400 resources functioning as the CIO for Excel Communications. Rick holds an MBA from the University of Texas. He can be reached at rick.rene@wavecreste.com. About WaveCreste WaveCreste is an IT professional services, consulting and outsourcing company helping clients leverage technology to improve business results. Our strategic approach to solutions delivery features onsite consulting expertise at the client site backed by offsite teams at our U.S. rural and near-shore centers. This approach provides clients with superior value and ease-of-management when compared to costly global consulting firms or offshore alternatives. WaveCreste was spun off from parent entity Genesis Networks in 2010 and has been delivering value for clients since WaveCreste is headquartered in San Antonio, Texas, with its flagship rural delivery center in Abilene, Texas, and locations throughout North America. 6

8 WaveCreste WHITE PAPER