Adopt a product oriented organizational structure
Agile Methodology Steps
Agile methodologies are of many kinds. We’ll discuss the most prominent onesamong them briefly. You can refer to a methodology as a specific set ofconventions your team chooses to follow. Your different teams can havedifferent methodologies. Agile methodologies are those which follow the corevalues and principles of Agile development we discussed before. There are thefollowing Agile methodologies: * Scrum * Kanban * DSDM (Dynamic Software Development Method) * Crystal Methodologies * FDD (Feature Driven Development) * XP (eXtreme Programming)Let’s discuss the primary ones below:
Methodology 3: Feature Driven Development (FDD)
Feature Driven Development focuses on building and designing the features. InFDD, your team would work in short phases that are highly specific and focuson working on an element. Design inspection, domain walkthrough, codeinspection, and promotion for building are some examples of the same. Insimple words, FDD focuses on feature-specific development.You’d have to work on component ownership, domain object modeling, regularbuilds, inspections, and feature teams. You must maintain proper visibility ofresults and the current progress of the project as well.
Methodology 4: Lean Development
The iterative development methodology of agile matches the principles of Leansoftware development. Lean aims to reduce the amount of work in the process tomanage the flow. This helps in enhancing the speed of delivery. Lean teamsfunction as “Just In Time” systems. This means that they have to wait untilthe last required moment for making decisions.Lean focuses on the removal of waste. And according to Lean principles,anything which the customer won’t pay for is a waste. It also focuses onautomating processes that are repeatable and are highly prone to human errors.
Become a Full Stack Developer
UpGrad and IIIT-Bangalore’s PG Diploma in Software DevelopmentLearn MoreAn operating model for company-wide agile developmentMany digital companies are using agile development practices to deliver goodsand services to customers more efficiently and with greater reliability. Usingthis software-development approach across all business units and productgroups, digital giants have been able to design and build features quickly,test them with customers, and refine and refresh them in rapid iterations.By contrast, few traditional companies—those with both online and offlinepresences—are using agile methodologies across the majority of their product-and application-development teams. Many banks, for instance, have establisheddigital units to develop and release mobile apps or website features quickly.But those groups typically remain physically and strategically disconnectedfrom the rest of the IT organization and the rest of the company.Research indicates that many traditional companies are experimenting withagile practices in discrete pilot projects and realizing modest benefits fromthem. But fewer than 20 percent consider themselves “mature adopters,” withwidespread acceptance and use of agile across business units. Meanwhile,according to our own observations, the companies that are deploying agile atscale have accelerated their innovation by up to 80 percent.There are many reasons traditional companies have not been able tosuccessfully scale up their agile programs, but we believe a chief impedimentis their existing operating models and organizational structures. In most ofthese companies, the process of software or product development remainsfragmented and complex: a business request for a new website feature can kick-start a development process involving multiple teams, each tackling a seriesof tasks that feed into the original request. For instance, one team workingon the front-end application, another updating associated servers anddatabases, and still another reconciling the front-end application with legacyback-end systems. What’s more, the supporting business processes (among them,budgeting, planning, and outsourcing) and existing roles and responsibilitiesin both the IT organization and business units continue to adhere closely tothe legacy waterfall approach.Would you like to learn more about Digital McKinsey?For most companies, it will be difficult to incorporate agile practices fromsmall-scale pilots into all business units and functions—regardless of thesuccess of those pilots—without making significant structural changes.We have helped many organizations adopt agile development practices in theirIT and business groups. Building on that base, we recently studied in depth 13large traditional organizations that are implementing agile methodologiesacross functions and business units (see sidebar, “Launching agile at scale:The research base”). To facilitate widespread adoption, these companies havemade changes in one or more parts of their operating models, targeting thefollowing four areas: modifying their organizational structures to be moreproduct oriented, improving interactions between the business and IT,redefining roles within business units and the IT organization, andreconsidering their budgeting and planning models (exhibit).ExhibitWe strive to provide individuals with disabilities equal access to ourwebsite. If you would like information about this content we will be happy towork with you. Please email us at:McKinsey_Website_Accessibility@mckinsey.comThe companies that have started on this path to change are realizing earlybenefits. One has switched from a project- to a product-oriented operatingmodel. It has deployed talent and IT resources based on IT requirements forthe entire customer-onboarding experience, for instance, rather than accordingto individual applications used during onboarding. As a result of this changein focus, it is now launching up to four website features a month instead ofthe typical four a year the company was able to release previously. Thissuccessful shift to agile was made more attainable when the company carefullyconsidered when and how to phase in various modifications to its operatingmodel.
Scaling agile practices
The benefits of agile are by now well known. Under agile developmentmethodologies, IT organizations and product developers cocreate products andservices with the business, rather than simply collecting featurespecifications and throwing them back over the wall, as would happen under thewaterfall development model. Teams can experiment with minimally viableproducts, test and learn from those prototypes, and ultimately deliver newsoftware features and products in days or weeks, not years. Based on ourobservations of leading-edge adopters, quick codevelopment of products andcollaboration among highly skilled IT and business professionals can happen ona broader scale when companies take steps to remake their operating models andorganizational structures, focusing in particular on these four principles.
Adopt a product-oriented organizational structure
Traditional companies tend to organize their IT resources according toapplications and projects—creating the type of fragmented developmentexperiences described earlier. Instead, they need to organize IT resourcesaround products, gathering business-unit leaders, developers, and othermembers of the organization in stable end-to-end teams that are focused ondelivering designated business outcomes. Such a structure would mean the endof projects as they are traditionally defined and of coordination bodies suchas the project-management office.In an agile-at-scale environment, products can’t be defined solely ascommercial offerings. They may actually be combinations of offerings (forinstance, a payroll service), or the customer experience (say, all thefeatures and tasks that make up the online purchasing journey), or an ITsystem shared by multiple product teams (such as pricing software thatgenerates quotes on demand). So it’s important for business and IT leaders toredefine the units of delivery. And once products have been recategorized, thecompany must designate an agile team, or clusters of agile teams, that will beresponsible for the development and maintenance tasks associated with thoseproducts. These teams typically will include developers, testers, productowners, and others. They can draw additional support from a centralized groupof experts—specialists in security issues, user-experience researchers, orenterprise IT architects, for instance.A large medical-device manufacturer significantly shortened its time to marketby refining its organizational structure. Under its traditional structure,there could be as many as 20 handoffs when a business unit shared itsspecifications and requirements with the technology organization for a newpiece of software or an additional feature in existing software. Because ofthe interdependencies among its products, leadership knew it wouldn’t beenough to deploy agile within one business unit or within certain product-management teams in the technology organization. In 2015, the company tweakedits product-ownership model so that software requirements were directlytransmitted from dedicated product owners in the business units to the agileteams, rather than passing through multiple parties. With this change, thecompany was able to reduce the amount of time it took to release products inthe market. The structural changes also facilitated the rise of severalcommunities of practice. These role-based or topic-based groups (sometimescalled guilds) are critical in agile-at-scale environments. They can encouragethe transfer of knowledge among team members, promote coordination betweenteams and functions, and become the catalyst for continuous performanceimprovement.
A waterfall approach (Figure 4.3) involves treating the steps of a project asseparate, distinct phases, where approval of one phase is needed before thenext phase begins. For example, the Design phase does not begin in earnestuntil requirements have been approved by business stakeholders, who sign offon one or more requirements documents at the end of the Define phase.Figure 4.3 Example of a waterfall approach, where each phase “falls” into thenextThe problem with a pure waterfall approach is that it assumes that each phasecan be completed with minimal changes to the phase before it. So if you comeup with new requirements in the Design phase, which is common, you mustsuggest changes to documents that were approved at the end of the Definephase, which can throw off the plan and the schedule.
Because change is constant, project teams are continually looking for moreflexible approaches than the waterfall model. Many methodologies follow a morefluid approach, with some steps happening alongside each other; for example,versions of the website could be released on a rapid, iterative schedule usingan agile or rapid development approach (Figure 4.4). An agile approachgenerally has a greater focus on rapid collaboration and a reduced focus ondetailed documentation and formal sign-off.A true agile approach (following the best practices developed by members ofthe Agile Alliance, for example) calls for small teams whose members arelocated next to each other physically, with little focus on defining formalroles between team members. Working this way allows a very high degree ofcollaboration, which reduces the need for heavy documentation between thestages of design, development, and testing. A team member can pose a question,come to the answer together with other team members during a quickwhiteboarding session, and implement a solution without the delay of detaileddocumentation and approval. Stakeholder reviews occur with a fully functioningsystem when one of the many iterations is released, and the resulting input istaken into account as the next iteration is planned. (Iterations are draftversions of a particular site or application and may also be called sprints.)Designers moving to an agile approach for the first time often face aconundrum. How do you go from a waterfall approach (which favors detaileddocumentation and sign off, taking weeks or months per phase), to an agileapproach (which favors conversations and quick decision making over the courseof days or weeks) and still make time for design thinking and user research?To see how some designers have made the transition, let’s dive deeper into aparticular kind of approach called Lean UX.
Lean UX is an agile project approach that’s well-suited to products beingdeveloped in the face of great uncertainty (as most products for startupsare). It reduces waste in the project’s process by removing effort spent onfeatures that don’t really matter at the time of each iteration. For example,spending time designing an entire set of categories and subcategories ofproducts may be wasteful if the team has not yet proven that they’re offeringproducts that their target users are willing to purchase.Some of the principles of Lean UX include: * A focus on validated learning. Iterations of the product are not seen as simply working versions of the product, but as the presentation of a hypothesis that can be tested with users. The goal is to learn as quickly as possible, by validating design decisions with customers and incorporating the subsequent changes that will help the team learn the next important lesson. * A continuous loop of Build—Measure—Learn. Lean processes prioritize the building of a testable iteration of the product as quickly as possible, in order to test assumptions that the team is making about how users will react to the product. Tests fail or succeed based on qualitative user feedback during research, and on quantitative measures that are put in place to track success. These measures should pull from actual user behavior—for example, the number of registrations for a site, the number of products purchased, and so on. Care should be taken that the measures put in place really test the assumptions of that iteration. For example, if people are registering for your site, but not taking any important actions in it afterwards, you’ve just learned that your post-registration experience needs to be more compelling! Incorporate that learning into your decisions on what goes into the next build, and complete the loop (Figure 4.5).Figure 4.5 Lean approaches focus on a loop of Build—Measure—Learn. The processis meant to increase the speed by which teams cycle through the loop,maximizing learning and allowing for quicker adjustments in strategy based oncustomer response. * The importance of developing the Minimum Viable Product (MVP) at each iteration. In a lean process, the focus is on testing a hypothesis about user behavior, rather than building a fully functioning product at each iteration. Teams don’t need to create a fully functioning digital version of their product to test a hypothesis (although a more robust digital version will eventually exist after several cycles, if things are going well on the validation front). Especially in beginning stages teams can focus on developing a Minimum Viable Product, which Eric Ries defines as “that version of product that enables a full turn of the Build—Measure—Learn loop with a minimum amount of effort and the least amount of development time.” For example, elements of the experience that should eventually become automated—like confirmation emails when a purchase has been made—may be completed more manually by a team member while the test is being run in an earlier iteration. * A move away from formal deliverables and detailed documentation. This is consistent with the overall agile approach. Deliverables like detailed wireframes and use cases, which may become replacements for direct communication and fast implementation of ideas, are removed from the process in favor of faster methods like sketching. Conceptual wireframes are often still used, but are meant to illustrate quickly as an aid to communication, and do not “live on” as records of design decisions.When an agile approach is working as it’s designed to, it’s a beautiful thing.At most companies and within most consulting engagements, however, teamsrarely follow a pure agile approach. In part, this is because companies oftenhave distributed teams and remote workers, which makes it difficult tomaintain the high degree of collaboration needed to take best advantage of thepure agile approach. However, a greater prevalence of virtual collaborationtools and digital sketching tools makes this distributed agile approachincreasingly possible, as long as teams commit to clear communication, highavailability, and effective decision-making.
Pros and Cons of Agile and Waterfall Methods
Modern software development approaches have developed as quickly as they’vedelivered items. Numerous practices and procedures currently exist, likewiseeach individual team’s unique components.Still, two of the most widely recognized and all-enclosing methodologies arethe agile and waterfall processes to development. While they contain a largenumber of similar components, the two methodologies are boundlessly unique.Project management software tools are a key segment to keeping teams on track.These tools often vary in their feature sets, some favoring long-term,waterfall planning, while others are adapted towards the quick-paced agilemethodology.
Agile project management is based on quick iteration and user testing. Whiletraditional procedures focus on long-term objectives and illustratingprerequisites in advance, agile teams take a pick-your-own-adventure’approach. After continuously testing, pitching ideas and hearing from users,agile software development plan to form final products around users’ needs bylearning what the products are as they go along. Well known items: JIRA,Targetprocess, Telerik TeamPulse, and Pivotal Tracker.
Here is the regular, safe approach for managing software development. Teammembers and managers layout all requisites up front. From that point, strictschedules are closely monitored. Before teams move to a new phase of thesequential development schedule, requisites must be met and tasks must bedone. Rather than testing changes throughout the process, teams develop anear-complete product and push it to user testing at a predefined date.Popular products: LiquidPlanner, Microsoft Project, Smartsheet and Basecamp.