Challenging ALM: What really matters when picking tools? Share this Ebook

Transcription

1 Challenging ALM: What really matters when picking tools?

2 Beyond features, performance and price. It is a given: software teams must rapidly respond to change to keep pace. Or risk the software they create being obsolete/uninstalled/in a folder named Trash. Software development tools are an often overlooked part of how teams respond to change - bad tools leave your teams hamstrung, good tools help you collaborate. Teams generally evaluate tools based on features, performance, and price. But, there's more to it. Tools that are focused on reports or top down decision-making over productivity are bad tools. Good tools empower teams to make the best decisions to get their work done. Tips for picking tools that help you deliver Change and grow with your teams Let your teams be different Help you build the right thing over following the right process Help you deploy often and fail fast Make real progress, not rigid plans on paper

3 Tip #1: Your tool must change and grow with your teams The way your team works and the processes they use keeps changing. Business realities demand it. Your tools cannot afford to be the rigid framework they have to keep conforming to. Evolving processes require tools that enable on-the-fly changes and continuous improvement. Tools that adapt to the way a team works and grows get used across the team throughout the project lifecycle. Thus they hold accurate and relevant information of project status and progress. This provides visibility for your team to see, manage and respond to change. Agile processes are generative, not prescriptive. Processes need to evolve as needed, not be prescribed up-front. A prescriptive approach generates complex and complicated processes whereas a generative approach begins with a set of simple processes and adds others as they are needed. - Jim Highsmith, author of Agile Project Management CAUTION: Avoid Cosmetic Customization! On the surface, some tools allow users to define their process up-front by adding fields into a template, creating workflows, defining reports, etc. However once the project gets underway, they can no longer be further customized to accommodate future process changes. Thus these tools end up slowing things down by getting in the way of change.

4 Tip #2: Your tool should let your teams be different Every team and project is different. Just as processes cannot be completely defined up-front, they also cannot be completely standardized across all teams. Embracing differences in teams requires tools that support the way that the team works best one that is uniquely tailored to their circumstances and needs. While promoting diversity, tools must also support a common language across projects to facilitate governance and compliance, as well as providing stakeholders a comprehensive view of all projects. A consequence of self-adaptivity is that you should never expect to find a single corporate methodology. Instead, each team should not just choose their own process, but should also actively tune their process as the project proceeds. - Martin Fowler, co-author of the Manifesto for Agile Software Development MYTH: Standardized processes reduce risk! Standardization reduces both the low-performing variations, and the high. This makes it harder for teams to excel, and can institutionalize mediocrity. Instead, tools should support the team s natural ways of working, and give them the control and confidence to develop and improve their processes.

5 Tip #3: Your tool should help you build the right thing, over following the right process Agile projects in particular, work better when customers collaborate closely with the delivery team. They can then see the software as it's being created and provide continual feedback to ensure that the team builds what they want. Building the right thing requires tools that facilitate dialogue and collaboration throughout the development process. The tools must help all roles on the team work together to correctly define requirements, oil a short feedback loop and help the teams to release regularly the best way to ensure the team is building the right thing. The pace of change is accelerating, and businesses need to move fast to keep up. If you're not constantly delivering working software, you're not getting feedback on whether what you're delivering is useful. The longer it takes you to get feedback and pivot, the more time and money you spend on building the wrong thing. - Jez Humble, author of Continuous Delivery BEWARE: Don t focus on requirements Focus on what the customer wants. ALM tools often force teams to focus heavily on adherence to a requirements lifecycle. However, this also forces them to take their eyes off of meeting the customer's actual needs, or changes in their needs.

6 Tip #4: Your tool should help you deploy often and fail fast Agile projects emphasize frequent delivery of smaller chunks of software. Practicing Continuous Delivery (CD) ensures a clear path to production issues in the release process are ironed out early and releases are predictable. CD requires tools that help you deploy often, so you can fail fast, pick up the pieces quickly, and improve. The tools should help everyone on the team self-service their builds, test the right things and quickly find and fix the broken stuff, all while maximizing automation. This helps your teams release frequently and predictably. Keeping your software production ready from the beginning of the delivery process has several benefits. First, it means releasing is a low-risk, push-button process. So you can do it more often, get frequent feedback from users, test it often under realistic conditions, and get the only real measure of product progress. In short, you can deliver higher quality software faster, and reduce waste in your delivery process. - Jez Humble, author of Continuous Delivery REALLY: Releases should be boring! Manual deployments, heavily silo-ed teams, dependence on DevOps, incomplete testing and frequent rollbacks all result in yet another stressful release! Tools that facilitate CD provide a common platform for build-test-release - allowing everyone to self-service their builds, test exhaustively, automate the delivery process and have an active stake in the release. Thus making releases boring non-events.

7 Tip #5: Your tool should help you make real progress, not rigid plans on paper Agile projects require leaders and managers to become orchestrators, aligning work with business goals, removing obstacles, fixing bad projects, understanding the portfolio, and helping to spread best practices across teams. This requires tools that provide radical transparency, visibility and flexibility. They must make it easy to monitor realtime progress, see dependencies among projects, highlight risks and successes. Thus enabling the business and software teams to collaborate closely and be more aligned to each other s needs. Governance is about monitoring investment and risk, not checking-off process steps. In fact, the key to effective executive project oversight is separating governance from operational processes, evaluating investment and risk at key project milestones and generating the data for that evaluation through iterative delivery. - Jim Highsmith, author of Agile Project Management FALSE: Governance is all about process compliance. Traditional ALM has historically confused process compliance for governance. These heavyweight tools encourage managers to mandate uniform process adherence. Thus many teams spend most of their time managing artifacts and working around mismatches among processes, tools, and reality all at the expense of delivering working software.

8 Tool must-haves Agile tools must support the 5 key organizational practices Enable teams to discover and evolve their process on-the-fly. Support the unique needs of every project, as well as the organizational needs for consistency. Facilitate constant collaboration among practitioners and stakeholders at all levels. Help teams to fail fast, learn fast and release faster to enable Continuous Delivery. Provide complete transparency and visibility for leaders, as a consequence of being used by all on the team, and not by creating additional work for the team. About ThoughtWorks ThoughtWorks, Inc. is a global IT consultancy providing Agile-based systems development, consulting and transformation services to Global 1000 companies. It has pioneered many of the most advanced and successful Agile methods of software development and best practices used in the industry today. At its core, ThoughtWorks helps its clients maximize investment and performance across a portfolio of complex, business-critical applications, while reducing time and risk. Its products division, ThoughtWorks Studios, makes pioneering tools for software teams who aspire to be great. Its products, Mingle, Go and Twist help organizations better collaborate and deliver quality software. ThoughtWorks employs 2000 professionals to serve clients from offices in Australia, Brazil, Canada, China, Germany, India, Singapore, South Africa, the United Kingdom and the United States.