Tips for success with adopting Agile - docs.media.bitpipe.com

E-Guide

Tips for success with adopting Agile Agile’s the great buzz word these days, but how many people are really practicing Agile and for how long? When the going gets tough, do they revert back to familiar, traditional habits? Readers will learn: •

Expert tips for transitioning to Agile

•

How to prove the business value of Agile strategies

•

Strategies for facing challenges with Agile project teams

Sponsored By:

SearchSoftwareQuality.com E-Guide Tips for success with adopting Agile

E-Guide

Tips for success with adopting Agile Table of Contents Adopting Agile: Eight traction tips to make Agile development stick Agile development: The whole-team approach About IBM

Sponsored By:

Page 2 of 10


Adopting Agile: Eight traction tips to make Agile development stick By Yvette Francino Agile’s the great buzz word these days, but how many people are really practicing Agile and for how long? When the going gets tough, do they revert back to familiar, traditional habits? At the inaugural Mile High Agile conference, keynote speaker Jean Tabaka encouraged attendees to “lean in,” and to keep practicing Agile even when the going gets hard. Later that day, Howard Deiner of Deinersoft, Inc. gave a presentation entitled, “How to make sure that Agile sticks,” giving eight “traction ideas” that will help make your Agile transition successfully sticky. Speak business benefits One of the first rules of thumb in Agile adoption is to ensure you have your leadership on board. In order to do this effectively, you need to speak the language the executives care about: business benefits. Managers may be wary of ideas such as self-organizing teams or switching methodologies without some evidence that Agile is going to solve their business problems. Deiner suggests, “Try couching your message less in terms of technology and more in terms of business value” with facts and statistics. Use lean terminology Though many executives may not know or want to know the details of software development methodologies, they often are quite familiar the lean production model popularized by Toyota in the 1990’s. Making your case for Agile using lean terminology may go far in winning the hearts and minds of management. The four basic lean principles include: Add nothing but value (eliminate waste) Center on the people who add value

Sponsored By:

Page 3 of 10


Flow value from demand (delay commitment) Optimize across organizations The seven types of waste identified in lean (overproduction, inventory, extra processing, motion, defects, waiting and transportation) can be found in software development. By identifying areas of waste and how those can be eliminated with an Agile methodology, many business people will readily jump on the Agile bandwagon. Give trust and honesty a chance Agile development changes the old “command and control” management model to a model that is collaborative and “people-centric.” The Agile model stresses transparency, allowing employees “non-punitive accountability.” In order for this type of environment to thrive, trust and honesty must be present. Management must trust their staff and empower them to take risks and step out of their comfort zones without fears of retribution. Deiner quoted one of America’s best known CEOs Jack Welch as saying, “…leaders establish trust with candor, transparency and credit. When leaders do not do this, they foster an environment of suspicion.” Banish cargo cultism Deiner described “cargo cultism” as an attitude of one in which people ask for a checklist of things to do that will make them “Agile” rather than using their minds to come up with the unique version of Agile that will fit their organization. The term “cargo cult” originated from Richard Feynman who spoke of “Cargo Cult Science” at the 1974 Caltech commencement ceremony. Feynman described a “cargo cult” of people who saw airplanes loaded with goods, so they built runways, but no planes landed. Feynman said, “So I call these things cargo cult science, because they follow all the apparent precepts and forms of scientific investigation, but they're missing something essential, because the planes don't land.”

Sponsored By:

Page 4 of 10


There is no cookbook that will tell you exactly what you need to do to be successful with Agile. It is not simply about following a spelled-out process. You need to think and continually adapt, adding the essential “ingredients” that will make Agile work for your team. Avoid “Scrummerfall” “Scrummerfall” is the term Deiner used to describe projects that claim to be Scrum, but are still using waterfall approaches. Four examples he gave were: The “waterfall process hiding inside Agile terminology.” Iterations are used, but development still progresses in a traditional fashion. The component-based development model, where we build horizontal layers rather than vertical feature-based development. Teams of specialists that work in an assembly-line fashion. Using Agile for development, but using waterfall for testing. Get the roles right Deiner spoke of the importance of having the right people, particularly for the Product Owner and Scrum Master roles in a Scrum environment. He warned first of the danger of “Product Owner by proxy,” where someone has delegated authority, because the person who should be making the decisions about the business is too busy. Another variation is the “committee of product owners” leading to poor and slow decisions. “Without a strong Product Owner who has the time and interest in making the project succeed, you are pretty much guaranteeing that your project will fail,” says Deiner. Similarly, it’s important to have a dedicated Scrum Master who understands and has the right skill-set for that role. Too often, organizations use a “matrix” model where Scrum Masters have multiple teams to facilitate, or they ask a technical lead or worse, the Product Owner, to wear two hats.

Sponsored By:

Page 5 of 10


Don’t plan to fail with the wrong setting It’s important with Agile transformation to start with the right project. It’s not a good idea to start with a project that’s too critical and have unrealistic expectations about being able to turn around a troubled project. The types of projects Deiner warned against using as your initial transformation project into Agile included: Projects which are already late. Projects which are so critical that should they fail, there will be serious business implications. Projects that have fixed deliverables on a fixed timeline with fixed resources. Projects that have already picked a process tool and have all roles prefilled, even before training. Agile transformation takes time. Use retrospectives to learn from each project. Start with basic training, then coach Deiner’s final point stressed the importance of training and the difference between training and coaching. He stressed spending the time to make sure the entire organization is trained, including the delivery team, the management team and all stakeholders. More detailed training should be provided for Scrum Masters and Product Owners, but everyone needs a foundation. Training won’t be enough for those with no experience. Coaches should be used to help motivate and teach the team how to apply the skills they’ve learned in the classroom to their project. Transitioning to Agile isn’t easy, but with these eight traction tips, your organization will stick with it until it becomes a part of your culture and brings you the success you’re looking for.

Sponsored By:

Page 6 of 10


Agile development: The whole-team approach By Lisa Crispin A hallmark of Agile development is the “whole-team” approach. On Agile teams, it’s not only testers or a QA team who feel responsible for quality. Every team member, including programmers, business analysts, database experts, technical writers and system administrators, commit to delivering the highest possible quality software product, and make that commitment meaningful. In Agile, we don’t think of “departments” or “groups,” we think of the skills, knowledge and tools we need to deliver good software. Most importantly, we apply the values and principles of the Agile Manifesto to identify problems that get in the way of quality and solve them. To paraphrase Elisabeth Hendrickson’s definition, Agile development is delivering business value frequently, at a sustainable pace, while adapting to changing business needs. This is the job of the whole team, not just testers or designated QA professionals. Tests drive coding from the unit level on up, and testing helps the team learn how the application should work, or when we’re “done” with a particular user story. And, again quoting Elisabeth, testing isn’t a phase. It’s an integral part of software development, just as important as coding. Agile project teams Each Agile team must possess all the skills needed to produce high-quality code that provides the required features. While this often means including specialists on a crossfunctional team, such as expert testers, it doesn’t limit particular tasks to designated team members. Any task may be taken on by any team member or pair of team members. The whole team takes responsibility for all testing activities, such as automating tests and doing manual exploratory testing. As a result, the whole team thinks constantly about designing code that makes these tasks easier to complete. They work together to keep technical debt at a manageable level. The whole-team approach requires constant collaboration. Testers work together with programmers, customers and other team specialists, not only for testing tasks, but activities

Sponsored By:

Page 7 of 10


such as building infrastructure and designing code for testability. Anyone may ask for, and receive, help at any time. Team members have a range of skill sets and experience, and apply these to solve challenges such as how to elicit examples of desired system behavior from customers and turn those into tests. Diverse viewpoints mean better tests and better quality. You don’t have to work on an Agile project to collaborate with people in different roles. When I worked as a tester on traditional phased-and-gated projects, I used my own initiative to get myself invited to requirements and design meetings. I developed personal relationships with programmers to start testing long before the “coding” phase was over. But, as Janet Gregory and I point out in our book Agile Testing: A Practical Guide for Testers and Agile Teams, there is a difference between having team members “representing” their functions in a cross-functional team, and becoming true team members of the team for as long as the team exists. Team structure Agile teams vary in structure according to the size and nature of their projects. Large companies with several large concurrent projects may choose a matrix-type structure, where people from different functional areas form a virtual team but still report officially to their individual departments. Some people with unique, specialized skills, such as security experts, might need to be shared among several teams. In my experience, having a permanent cross-functional team is preferable to a matrix organization. Learning to truly work together as a team takes years. If projects are short and teams are constantly changing, it’ll take a few iterations in each new project for members of the new project team to get used to working with each other. As we say in Agile Testing, “The best teams are those that have learned to work together and have developed trust with one another.” Challenges in the mainstream Early Extreme Programming (XP) teams were generally small and co-located. The principles and values of XP, as well as the physical workplace layout they encouraged, helped my first

Sponsored By:

Page 8 of 10


XP team to proactively adopt a whole-team approach. Working in an open team room with pairing stations made it seem natural for me to pair with a programmer writing unit tests. When I needed help automating GUI tests, a programmer was always on hand. We learned together that customers own external software quality, and helped them capture their quality criteria as tests. As Agile has grown into the mainstream and larger companies adopted it, the old role silos – development team, QA team, analyst team – are often replaced by Scrum team silos. This causes new problems: each team is re-inventing the wheel, not sharing knowledge and expertise. A whole-team approach to quality within one team is good, but the commitment to quality has to extend throughout the company. Coordination practices such as a daily Scrum of Scrums to address impediments help. Communities of practice (CoP) for each role help drive inter-team communication. For example, everyone interested in testing can share techniques and ideas through a testing CoP. If one team implements successful automated CI, they can demonstrate that to all the other teams. Large teams, especially where members are distributed geographically, bring a new dimension to the whole-team approach. Building trust among dispersed team members takes creativity and true commitment. We have to work harder to bridge the gaps, taking advantage of technology that keeps us connected by video, wikis and screen sharing. Regardless of challenges, the whole-team approach has proven time and time again to provide organizational benefits. In part two of this series, I give specific real-life examples of how my team has benefited from the use of the whole-team approach and explain why this approach will prove valuable both to your organization and to your customers.

Sponsored By:

Page 9 of 10


About IBM

At IBM, we strive to lead in the creation, development and manufacture of the industry's most advanced information technologies, including computer systems, software, networking systems, storage devices and microelectronics. We translate these advanced technologies into value for our customers through our professional solutions and services businesses worldwide.

Sponsored By:

Page 10 of 10

Tips for success with adopting Agile - docs.media.bitpipe.com

Recommend Documents