Being Agile: Your Roadmap to Successful Adoption of Agile

Being Agile: Your Roadmap to Successful Adoption of Agile

Mario E. Moreira

Language: English

Pages: 268

ISBN: 143025839X

Format: PDF / Kindle (mobi) / ePub


Being Agile is your roadmap to successfully transforming your organization to an Agile culture. Veteran agile coach Mario Moreira teaches new adopters how to implement a robust Agile framework to derive from it the maximum business benefit in terms of customer value, revenue, and employee engagement. 

Agile is a ubiquitous watchword in the corporate world, but only a minority of companies understand and practice what they pay lip service to. Too many content themselves with half-baked approximations such as Fragile (fragile Agile), ScrumBut (Scrum but not the practices), and Scrum Fall (mini-waterfalls in the sprints). Moreira shows maturing early adopters how to bridge the chasm between going through the motions of doing Agile and genuinely being Agile.

After a high-level synopsis of Agile’s values and principles, methodologies (including Scrum, Kanban, DSDM, Leam, VFQ, and XP), and roles, Moreira plunges into the nitty-gritty of how to apply the ready, implement, coach, and hone (RICH) deployment model to all phases of a project in such a way as to embody and inculcate agile values and principles at the team level and promote agile transformation across your organization's culture.

The Unbounded Mind: Breaking the Chains of Traditional Business Thinking

Better Than Good: Creating a Life You Can't Wait to Live

The Social Media Bible: Tactics, Tools, and Strategies for Business Success (Wiley Desktop Editions)

Taking the Stage: How Women Can Speak Up, Stand Out, and Succeed

Challenge the Ordinary: Why Revolutionary Companies Abandon Conventional Mindsets, Question Long-Held Assumptions, and Kill Their Sacred Cows

Winners Never Cheat: Even in Difficult Times (New and Expanded Edition)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

incorporated in the working software of the current version. In addition, it is beneficial to use the Product Owner (PO) as the delegated voice of the customer to solicit acceptance criteria on what the customer would expect when they see a particular requirement or feature in action. You may also conduct periodic customer surveys to gauge their level of satisfaction with the product or solution. 81 82 Chapter 9 | Achieving an Agile Mindset What actions exhibit “satisfying customer with

level of belief? • Do you believe in simplicity, removing waste, and continuously prioritizing requirements based on customer value? Self-Organizing Teams The best architectures, requirements, and designs emerge from self-organizing teams. Self-organizing teams have a combination of greater ownership and responsibility to achieve a common goal of building valuable software and reducing dependency on management. The team has the authority to be self-organizing and make decisions regarding

observe an Agile Team when they take training and when they participate in the agile events. Such evaluation should be done discreetly and privately. It is only meant to gain an understanding of willingness so you can adapt along the way with the goal of improving willingness. More important, this evaluation becomes a risk indicator of whether there is willingness for a successful agile transformation. You should consider each person on the team according to his or her willingness. The key is to

Path Ultimately success is measured by an increase in revenue. Having a customer revenue metric helps you understand whether company products are increasing revenue. Capturing revenue is a good starting point. However, it is a lagging indicator and resulting outcome. To supplement lagging measures, you need leading measures that provide you with visibility into what is currently occurring within the organization. This visibility is important because it provides input for making decisions as you

burnup. The difference between a burndown and burnup is that instead of tracking how much work is left, a burnup tracks how much work a team has completed, so the line goes up, not down (see Figure 14-4). The other difference is that in a Sprint, we know the target velocity so we can burn down from it. However, at the release level, because we purposefully avoid big up-front scoping of the work so we can adapt to change, we do not know our release scope or our velocity for the entire release.

Download sample

Download