Loading...

Follow Age of Product – Agile best practices with Scrum, LeSS & Lean Sta.. on Feedspot

Continue with Google
Continue with Facebook
Or

Valid


Food for Agile Thought’s issue #130—shared with 14,911 peers—covers once more the corporate agile failure at legacy organizations. We like the guide to suitable agile metrics by XSCALE Alliance’s Leon Tranter, and we deal with how to scale and align a growing engineering team.

We then dive deep into the psychology of creating products: from confirmation bias, Kahneman’s systems 1 and 2, the benefits of listening to talking, persuasion techniques, to 25 cognitive biases.

Lastly, we remember the project management nightmare called ‘waterfall.’

Have a great week!



The Tip of the Week Leon Tranter: Agile Metrics: the Ultimate Guide

Fellow XSCALE Alliance peer Leon Tranter provides a handy list of suitable agile metrics.

Corporate Agile Failure & Scrum Martina Hodges-Schell (via InfoQ): Agile: The Bad Parts

Corporate agile failure: Matt Parker and Martina Hodges-Schell dissect the failure of a former corporate client’s project that ballooned from 7 to 80 people.

Marcus Hammarberg: Some thoughts on organizing a team of developers

Marcus Hammarberg elaborates on how to organize and align a fast-growing engineering team properly.

Marketoonist | Tom Fishburne: The Art of Project Management cartoon

Tom Fishburne visualizes the origins of the need to abandon waterfall and start this whole ‘agile’ thingy with the Agile Manifesto.

Hands-on Agile: The Agility Assessment Framework (Workshop 2) — Berlin, March 10, 2018

Join us on March 10th, 2018 at the ThoughtWorks office to continue the work on Agility Assessment Framework—Hands-on Agile’s new open source project. We want to finish a prototype that enables practitioners to assess an organizations suitability to become an agile organization.

Read More: Hands-on Agile: The Agility Assessment Framework (Workshop 2)

Product & Lean Marc Abraham: My product management toolkit (26): PAUSE and LISTEN

Marc Abraham reflects why not listening to what the other person is saying is a mistake in product creation.

(via First Round Capital): Master the Art of Influence — Persuasion as a Skill and Habit

Tyler Odean shares his toolset for herding large organizations—engineers, designers, and executives—toward product decisions.

Marty Cagan: Waterfall Deconstructed

Marty Cagan captures the three indicators of a waterfall team.

Do Not Miss Out: Join the 2,600-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

Last Week’s Food for Agile Thought Edition

Read more: Food for Agile Thought #129: Mental Models, Resilience, Roadmap Questions, Combining Kanban and XP.

The post Food for Agile Thought #130: Corporate Agile Failure, Guide to Agile Metrics, Psychology Traps appeared first on Age of Product.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Food for Agile Thought’s issue #129—shared with 14,709 peers—covers mental models relevant to your agile journey and shares the download link to an excellent book on team-centric agile software development. (Yub, it is free of charge.)

We then dive into organizational resilience through business agility, what your stakeholders want to know regarding your product roadmap, and why loving your customers’ problems will make your life so much easier.

Lastly, Intercom’s VP of Product created an overview what product people with an agile mindset can expect from the organization. (And the good folks at Intercom are checking a lot of the right boxes!)

Have a great week!


The Tip of the Week Allan Kelly: Xanpan: Team-Centric Agile Software Development Combining Kanban and XP

Allan Kelly offers a free download of his new book ‘Xanpan: Team-Centric Agile Software Development Combining Kanban and XP.’

Mental Models & Agile Lisa Crispin: Retrospectives for large teams with many sub-teams

Lisa Crispin explains her approach to running a retrospective with 40-plus people spread across several locations.

Slava Akhmechet: Mental models

Slava Akhmechet aggregated a handy list of mental models—well suited for your agile coaching endeavor.

Steve Denning (via Forbes): Achieving Organizational Resilience Through Business Agility

Steve Denning on resilience, disruption, and the changing view of what constitutes proper management nowadays.

Use Burn-Down Charts to Discover Scrum Anti-Patterns

A burn-down chart tracks the progress of a team toward a goal by visualizing the remaining work in comparison to the available time. So far, so good. More interesting than reporting a status, however, is the fact that burn-down charts also visualize scrum anti-patterns of a team or its organization.

Learn more about discovering these anti-patterns that can range from systemic issues like queues outside a team’s sphere of influence and other organizational debt to a team’s fluency in agile practices.

Read More: Use Burn-Down Charts to Discover Scrum Anti-Patterns.

Product & Lean Paul Adams (via Intercom): What makes Intercom different, and better, for Product people

Paul Adams put together a compelling list of Intercom’s advantages for product people with an agile mindset. You can almost use it as a sort of checklist for agility assessments.

Rich Mironov: Your Audience's Real Roadmap Questions

Rich Mironov shares a slightly stereotyped view of stakeholders and their questions concerning product roadmaps.

(via Product School): Solving People's Problems as a Product Manager by Facebook PM

Aigerim Shorman discusses the mechanics of the product development process and the communication needed to ensure transparency.

Do Not Miss Out: Join the 2,575-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

Last Week’s Food for Agile Thought Edition

Read more: Food for Agile Thought #128: Disrupting Companies, Scrum@Scale Guide, Information Radiators.

The post Food for Agile Thought #129: Mental Models, Resilience, Roadmap Questions, Combining Kanban and XP appeared first on Age of Product.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
TL;DR: Use Burn-Down Charts to Discover Scrum Anti-Patterns

A burn-down chart tracks the progress of a team toward a goal by visualizing the remaining work in comparison to the available time. So far, so good. More interesting than reporting a status, however, is the fact that burn-down charts also visualize scrum anti-patterns of a team or its organization.

Learn more about discovering these anti-patterns that can range from systemic issues like queues outside a team’s sphere of influence and other organizational debt to a team’s fluency in agile practices.


Scrum Anti-Patterns Visualized by Burn-Down Charts

Burn-down charts have become popular to provide team members as well as stakeholders with an easy to understand status whether a sprint goal will be accomplished. (Critics of the burn-down chart may note, though, that a scrum team should have a gut feeling anyway whether the sprint goal is achievable.)

Hence, this post is focusing on another useful aspect of burn-down charts: they are equally well suited to provide additional insights into all kind of impediments, both at a team level and at an organizational level.

The following graphs visualize four of the typical anti-patterns that can be easily detected with burn-down charts:

1. Late Acceptance

The product owner accepts or rejects tasks only late in the sprint:

This behavior may be rooted in various issues, for example:

  • The absent product owner: The product owner is rarely available for the team to clarify matters and accept work. This is creating an artificial queue that has a diminishing effect on the team’s ability to deliver value by delaying the necessary clarification of tasks or the shipment of tasks themselves. (Note: LeSS susceptible for this effect when the product owner when not willing to delegate responsibility.)
  • The proxy product owner: The team is working in a remote setup and the product owner is not onsite with the rest of the team. (Note: A proxy product owner is usually not a solution as he or she will just increase the time for feedback and add to the communication problems.)
  • Consequences: There will likely be a spill-over to the next sprint as the feedback loop does not provide enough time to fix issues during the sprint. The team will probably not meet the sprint goal. If this not an isolated incident but a persistent pattern, action needs to be taken.

The Scrum Anti-Patterns Guide

This ebook covers over 160 Scrum anti-patterns, and it is available for free right here. Download the “The Scrum Anti-Patterns Guide” now!

The download is available as a PDF delivered to your email address. Please note that downloading this content will also subscribe you to our popular, professionally-curated weekly 'Food for Agile Thought' newsletter if you aren't already subscribed. (You may, of course, unsubscribe at any time.)

Success! Now check your email to confirm your subscription.

There was an error submitting your subscription. Please try again.

First Name
Email Address
We use this field to detect spam bots. If you fill this in, you will be marked as a spammer.
Download Now

We respect your privacy

2. Slow Progress

In this case, the graph is located above the line of the expected progress for the complete sprint length:

There are several reasons why this might be the case:

  • The ambitious team: The sprint goal is too ambitious and the team realizes only during the sprint that it will not deliver the sprint goal. (Note: It is okay to aim high and fail, however, it should not be the regular pattern as it is negatively influencing the trust of the organization in the team.)
  • The submissive team: The sprint goal is too ambitious from an engineering perspective. However, instead of speaking up, the team tries to make it happen thus failing at the end of the sprint.
  • Capacity issues: The capacity of the team changes after the sprint starts, for example, team members get sick, or they give notice and leave the team. (Note: Admittedly, this is hardly plannable anyway.)
  • Change of priorities: The team needs to address a critical issue—probably a bug—which leaves less capacity to accomplish the original sprint goal. (Note: Depending on the magnitude of the disturbance it might be useful to consider canceling the spirit. At least, the team needs to reduce original sprint scope—which may require a mid-sprint re-planning to determine whether a reduced sprint backlog will still deliver the original sprint goal.)
  • Outside dependencies: The team faces dependencies outside its sphere of influence not foreseeable during sprint planning. (Note: A classic systemic dysfunction.)
3. Scope Increase

The scope of work increases over the course of the sprint:

Most of the time, this pattern can be attributed to inadequate preparation:

  • Refinement failure: The scrum team fails to refine tasks accurately only to discover that the effort to create a valuable product increment is higher than originally expected. (Note: If this happens multiple time during the sprint then the team accepted stories into the sprint the team has not fully understood. This points at serious issues with the product backlog refinement process or the collaboration with the product owner in general.)
  • Dynamic sprint backlog: Urgent tasks are pressed or find their way into the sprint without compensation. (Note: Depending on the magnitude of the tasks, canceling the current sprint and focusing on the apparently more valuable new issues might be the better alternative. Unless, of course, those new issues are hacking the scrum process of sprint planning. There are several examples of this behavior: A manager pulls strings to get his or her task into a sprint or tasks are disguised as critical bugs that need to be fixed immediately.)
4. Early Finish

The team accomplishes the sprint goal way earlier than expected:

Of course, an early finish is the anti-anti-pattern if the team figured out how to deliver a task with much less effort than expected. Or the sprint goal could be achieved with fewer tasks that planned.

However, the positive news might also hint at some problems. Again, the reasons for this phenomenon are multi-faceted. My two top-candidates are:

  • The overly cautious team: The team probably overestimated the effort to be on the safe side with its prediction. (Note: This could indicate that the management tracks, for example, velocity as an important metric for the contribution of the team members despite its limited usefulness. Or the organization is output oriented and does not accept ‘failure’ as an option. In these cases, the organization is setting the wrong incentives. See also the Hawthorne effect.)
  • A hack for slack time: The team included buffer time to be able to address technical debt, its need for pairing or other issues that do not regularly receive attention and hence managed to finish early. (Note: This might indicate that the current allocation of resources is neglecting the long-term health of the team as well as the code base. Also, watch out for the feature factory syndrome where team utilization and output matter more than the long-term outcome.)

Use #BurnDownCharts to Discover Scrum #AntiPatterns
Click To Tweet
Conclusion—Use Burn-Down Charts to Discover Scrum Anti-Patterns

It is a good idea to use burn-down chart patterns for the next retrospective as they easily identify team problems or systemic dysfunctions. And utilizing burn-down charts in that capacity does not even require switching to story points per se—equally sized stories can just be counted to create a dimension for the y-axis.

Enhancing burn-down charts with additional data, for example, context and occurrences, as well as lead time and cycle time values, will increase the benefit of burn-down charts even more.

Speaking of which: At the team level, I would suggest creating a rotating scheme of team members to update the burn-down chart daily. It is a team exercise and not the job of the scrum master.

Lastly, no matter what purpose you are using burn-down charts for, avoid falling into a common trap: Start counting subtasks. This accounting will quickly lead you on the track of abandoning your definition of done. Instead, you will start marking tasks as 90 % complete. Welcome to cargo cult agile—how would that differ from the waterfall approach?

What scrum anti-patterns that burn-down charts can reveal are missing? Please share with us in the comments.

Do Not Miss Out: Join the 2,600-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

Burn-Down Charts—Related Articles

Download the ’Scrum Anti-Patterns Guide’ for Free

The post Use Burn-Down Charts to Discover Scrum Anti-Patterns appeared first on Age of Product.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Food for Agile Thought’s issue #128—shared with 14,506 peers—covers disrupting companies—seven habits that make any organization highly vulnerable—, Jeff Sutherland’s new framework to scale scrum, and the movements that inspire the future of work.

We then dive into the advantages of autonomous product teams and learn that a bug-free product is not necessarily a sign of a quality mindset.

Lastly, if your stakeholders believe your team is a black box, why not build an information radiator? C. Kyle Jacobsen can help you with that.

Have a great week!


The Tip of the Week: Disrupting Companies Larry Downes (via Harvard Business Review): So Your Company Has a Hit. What Next?

Larry Downes and Paul Nunes analyze the crisis of finding your company’s second act and identify seven habits of highly vulnerable enterprises.

Agile & Scrum Jeff Sutherland: Scrum@Scale Guide

Jeff Sutherland published the Scrum@Scale guide available as a free download.

(via Corporate Rebels): Rewriting The Future Of Work: 8 Movements To Watch

The Corporate Rebels link the eight building blocks of the organization of the future to inspiring movements worth watching.

Yassal Sundman (via Crisp): Stop Managing Bugs, Start Focusing on Quality!

Yassal Sundman urges you to change your attitude toward handling bugs—even ignoring them could be okay given the right mindset.

13 Signs of a Toxic Team Culture

What looked like a good idea back in the 1990ies—outsourcing, for example, software development as a non-essential business area—has meanwhile massively backfired for a lot of legacy organizations. And yet, they still do not understand what it takes to build a decent product/engineering culture. Learn more about typical anti-patterns and are signs that the organization has a toxic team culture.

Read More: 13 Signs of a Toxic Team Culture

Product & Lean Martin Eriksson (via Mind The Product): Your Team is Smarter Than You Are: Why Autonomous Product Teams Work Better

Martin Eriksson on the necessity to remove dependencies and thus friction between product teams.

C. Kyle Jacobsen (via Medium): The Why and How of Creating a Product Wall

C. Kyle Jacobsen shares how to help stakeholders understand what product and engineering are up to by adding transparency.

Sofia Quintero (via NomNom Insights): The Product Manager’s Guide to Change Management

Sofia Quintero addresses the essentials of change management from product management perspective.

Do Not Miss Out: Join the 2,500-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

Last Week’s Food for Agile Thought Edition

Read more: Food for Agile Thought #127: Useless Agile Metrics, CD Works, Product Experiments, Fewer Product Managers.

The post Food for Agile Thought #128: Disrupting Companies, Scrum@Scale Guide, Information Radiators appeared first on Age of Product.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Food for Agile Thought’s issue #127—shared with 14,292 peers—covers useless agile metric; we learn common excuses why continuous delivery would not work, and how to organize a big room planning.

We then talk about signs of a toxic team culture, how design thinking, agile and lean fit together, and what to do when a team fails to deliver at the end of a sprint.

Lastly, we learn why experiments do not just happen to the best organizations but perhaps create them, and what product thinking has to do with it.

Have a great week!


The Tip of the Week Allen Holub: KPIs, Velocity, and Other Destructive Metrics

Allen Holub explains why a taylorist approach to agile practices is ill-fated.

Focus on continuous process improvement, and productivity takes care of itself.

Useless Agile Metrics & Scrum Jez Humble (via Agile Testing Days): Continuous Delivery—Sounds Great But It Won't Work Here

Watch Jez Humble’s keynote from Agile Testing Day 2017—a handy list of excuses why CD supposedly would not work.

Ole Jepsen (via InfoQ): Scaling Agile – Big Room Planning

Ole Jepsen shares a comprehensive how-to of successfully scaling agile: aligning up to 100 people and figuring out what to build next in just two days.

Johanna Rothman: When Teams Don't Finish Work in a Sprint: 3 Tips to Seeing and Finishing Work

Johanna Rothman has three suggestions how to improve a team’s ability to accomplish the sprint goal.

XSCALE Alliance News

The Business Agility Institute (BAI) and XSCALE Alliance are teaming up. While the BAI provides the most comprehensive and detailed taxonomy of agile organizations today, XSCALE’s principles and pattern languages offer an agnostic praxis to fulfill the BAI taxonomy.​

Read More: XSCALE Alliance has agreed to a Memorandum of Understanding with Business Agility Institute.

Product & Lean Jonny Schneider (via ThoughtWorks): Understanding how Design Thinking, Lean and Agile Work Together

Jonny Schneider fights cargo cult agile by detailing how the three mindsets of product development can be used successfully beyond formalized processes.

Christian Rudder (via The OkCupid Blog): We Experiment On Human Beings!

Christian Rudder reveals a shocking truth: OkCupid doesn’t know what it’s doing. Moreover, probably you do not know either.

John Cutler (via Hackernoon): We Need Fewer Product Managers

John Cutler makes a compelling case that we need more product thinking and less product managing.

13 Signs of a Toxic Team Culture

What looked like a good idea back in the 1990ies—outsourcing, for example, software development as a non-essential business area—has meanwhile massively backfired for a lot of legacy organizations. And yet, they still do not understand what it takes to build a decent product/engineering culture. Learn more about typical anti-patterns and are signs that the organization has a toxic team culture.

Read More: 13 Signs of a Toxic Team Culture

#FoodForAgileThought #127: Useless Agile Metrics, CD Works, Product Experiments, Less Product Managers
Click To Tweet
Do Not Miss Out: Join the 2,450-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

Last Week’s Food for Agile Thought Edition

Read more: Food for Agile Thought #126: Agile Engineering, Swarming, Experimentation Culture, Metrics Fetish.

The post Food for Agile Thought #127: Useless Agile Metrics, CD Works, Product Experiments, Fewer Product Managers appeared first on Age of Product.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
TL; DR: 13 Signs of a Toxic Team Culture

What looked like a good idea back in the 1990ies—outsourcing, for example, software development as a non-essential business area—has meanwhile massively backfired for a lot of legacy organizations. And yet, they still do not understand what it takes to build a decent product/engineering culture. Learn more about typical anti-patterns and are signs that the organization has a toxic team culture.


The Toxic Team Culture: Internals vs. Externals

20 years ago, many large companies tagged along with Jack Welch’s philosophy of outsourcing non-core business areas — such as software development — to third parties. Today, they find it hard to compete in the war for product and engineering talent with the GAFAs and other agile and technology-focused organizations. Software is finally eating the world.

The lack of a product/engineering culture in those legacy organizations usually results in hiring numerous contractors and freelancers to get at least some projects going. Which in return often leads to some typical anti-patterns as the internals find it hard to team up with the externals:

No equality: There is a pecking order among team members. This order is not based on an individual’s contribution or capability but whether that person is on pay-role or not.

Externals to the shop floor: Externals are expected to deliver the work items. Accepting accountability and developing a sense of product ownership is regarded impeding this purpose.

Career issues: Internals focus on advancing their careers by other means than building an outstanding product, for example, by getting involved in the organization’s politics game.

Hiring minions: Internals claim the final say whom to hire and tend to use it to select submissive minions. (As the saying goes: B people hire C people.)

Lonesome decisions: Internals consider themselves responsible for the product and hence insist on making all decisions themselves—often single-handedly without involving the team or by overriding the team’s decision.

Assigning tasks: Internals dispatch work items to either externals or juniors. (It is even worse when externals accept the situation and ask internals what is the next work item for them is.)

No WiFi for you: Externals are excluded from the use of ‘internal’ infrastructure, for example, WiFi and calendar applications.


The Scrum Anti-Patterns Guide

This ebook covers over 160 Scrum anti-patterns, and it is available for free right here. Download the “The Scrum Anti-Patterns Guide” now!

The download is available as a PDF delivered to your email address. Please note that downloading this content will also subscribe you to our popular, professionally-curated weekly 'Food for Agile Thought' newsletter if you aren't already subscribed. (You may, of course, unsubscribe at any time.)

Success! Now check your email to confirm your subscription.

There was an error submitting your subscription. Please try again.

First Name
Email Address
We use this field to detect spam bots. If you fill this in, you will be marked as a spammer.
Download Now

We respect your privacy

The Toxic Team Culture: Equality and Diversity And then there are other issues beyond the internal vs. external question that might prevent a group of people that happen to be in the same place at the same time from becoming a team:

Not all developers are created equal: Merges need to be requested and are utilized as code quality stage-gates beyond a reasonable level.

Outsourcing to juniors: The senior team members consider writing tests, fixing bugs or documentation as a minor task below their pay-grade. Hence, it is outsourced to the junior team members.

Remote minions: Remote team members are not fully included, for example, they never meet the co-located team members in person.

The silent treatment: Team members are deliberately ignoring communication only to point at a later stage at a perceived lack of communication.

No diversity: The team members basically look the same, probably white dudes in their twenties and thirties.

Voting with their feet: The team suffers from a high fluctuation among its members.

13 Signs of a #Toxic Team #Culture
Click To Tweet
Conclusion:

What is difficult to understand is that legacy organizations complain that they cannot hire top engineering talent. On the other side, they do not invest in making the company a great place to work for in the first place. And by “great” I am not referring to sushi chefs on the premise or sparkling water from eight different countries in the fridge.

Creating balanced, diverse teams where rank does not have privileges—that are ready and willing to accept accountability—is essential for organizations striving to build a product/engineering culture or even become agile. Their return on investment will largely depend on achieving this goal as early as possible in the transition.

What signs of a toxic team culture have you observed? Please, share with us in the comments.

Do Not Miss Out: Join the 2,400-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

Related Articles

Download the ’Scrum Anti-Patterns Guide’ for Free

The post 13 Signs of a Toxic Team Culture appeared first on Age of Product.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
TL;DR: How to Measure Agility of Organizations and Teams

Is every organization suited to become ‘agile?’ If so: How to measure agility? And if not: Wouldn’t it be great figuring that out before embarking on a futile and expensive journey?

Back in October and November 2017, I ran a survey to identify contributing factors to an organization’s or a team’s agile maturity. In total, 86 people participated. Based on their answers, I aggregated a preliminary taxonomy of agility related factors.

This taxonomy was first presented on the Hands-on Agile Berlin meetup on November 30th, 2017.

On February 3rd, 2018, 20-plus people will join a hackathon to build an agility assessment framework based on this taxonomy. The goal of the workshop is to provide the first version of a tool that empowers agile practitioners to measure agility, be it an organization’s suitability for agile practices or a team’s progress on its path to becoming agile.


How to Measure Agility: The Current State

Measuring agility is nothing new. There are plenty of tools and approaches available, starting with Crisp’s Scrum Checklist to James Shore and Diana Larson’s Agile Fluency model. Measuring agility of prospective clients has become a valued presales tool for many consultancies, too.

What is missing today, though, is an open-source and thus widely available framework that any agile practitioner can use to get an understanding of her organization’s or team’s level of agility.

How to Measure Agility: Future Steps

On February 3rd, 2018, 20-plus people will join a hackathon to build an agility assessment framework based on taxonomy described below. The goal of the workshop is to provide the first version of a tool that empowers agile practitioners to measure agility.

‘Agility’ could be an assessment of an organization’s suitability for agile practices, providing an idea of the necessary steps for an organization that decided to become a learning organization. Questions that come to mind are, for example:

  1. Where are we now?
  2. Where do we want to go?
  3. What are the necessary steps to get there?
  4. Design a plan how to get there

The Berlin hackathon will be an experiment. For example, I wonder if we can apply analytical thinking–such as measuring factors and calculating states—to complex social systems? Or will that approach turn out to be a dead end?

How to Measure Agility: The Original Survey Questions

The 2017 agile maturity survey comprised of four questions:

  1. What factors contribute to a team’s growing maturity in agile practices?
  2. What maturity levels do you see at a team level?
  3. What factors contribute to becoming an ‘agile’ or a learning organization?
  4. What maturity levels do you see at an organizational level?

In total, 86 people participated in the survey: 13 from the corporation I am currently supporting and an additional 73 participants from the Age-of Product mailing list.

Agile Transition – A Manual from the Trenches

The latest, 181 pages strong version of "Agile Transition – A Hands-on Manual from the Trenches" is available right here, and it is FREE!

The download is available as a PDF delivered to your email address. Please note that downloading this content will also subscribe you to our popular, professionally-curated weekly 'Food for Agile Thought' newsletter if you aren't already subscribed. You may, of course, unsubscribe at any time.

That went well! Please check your email to confirm your subscription to our weekly “Food for Agile Thought” newsletter and download your free ebook 'Agile Transition – A Hands-on Manual from the Trenches'! NOTE: If you do not receive the confirmation email within about 10 seconds, please also check the spam folder. Thank you!

There was an error submitting your subscription. Please try again.

First Name
Email Address
We use this field to detect spam bots. If you fill this in, you will be marked as a spammer.
Download Now

We respect your privacy

How to Measure Agility: Preliminary Agile Maturity Indicators

From the answers, I derived the following taxonomy of indicators of agile maturity:

  • People and teams: Autonomy, Mastery, Purpose
  • Organizational Excellence
  • Technical Excellence
  • Communication & Collaboration

The slides of the presentation are available on SlideShare:

Let us dive deeper into the details of measuring agility:

People and teams: Autonomy Self-organization:
  1. Empower teams (Decisions, accountability)
  2. Focus on outcome
  3. Respect Scrum values (Commitment, focus, openness, respect, courage.)
  4. Safety to raise & discuss issues
  5. The team handles its own problems (No scrum mom.)
  6. Supporting each other as team members (Bonding.)
  7. Holding each other accountable (Agile is a team sport.)
Accountability (of the individual):
  1. Choosing tools & devices (e.g. software)
People and teams: Mastery Learning:
  1. Short feedback loops (User tests, customer development)
  2. Use of retrospectives
  3. Continuous team coaching (Guilds, code mentors etc.)
  4. Stakeholders live up to their responsibilities
  5. Hands-on experience over credentialism
Competence:
  1. T-shaped people
  2. Active knowledge sharing
  • Continuous learning
  • No withholding of knowledge
  • Knowledge sharing beyond the product and tech realm

  • Budget to attend conferences
  • Center of Excellence for Agile
  • Team building:
    1. Cross-functional teams:
    • No dependencies w/ other teams,
    • End-to-end delivery capability

  • Stable, long-living teams
  • Support by an experienced scrum master
  • People and teams: Purpose Inclusion
    1. Product discovery
    2. Product roadmap creation
    3. Release planning
    Organizational Excellence Culture:
    1. Embrace and celebrate failure (Validate hypotheses by running experiments)
    2. Curiosity as a norm
    3. Undogmatic attitude, live Shu-Ha-Ri
    • Transparency:
    • Share information and data at all levels,
    • No more gated information or information brokers

    Leadership:
    1. Focus on innovation, quality and business value (No more HIPPOism.)
    2. Supports of ‘agile’s way of working’ fully
    3. Enforces ‘agile’ as the core of the company culture
    4. Respect for roles, principles, and processes (The ‘real’ PO.)
    Management:
    1. Managers to servant leaders
    2. Trust in people and teams
    3. Provides tools and facilities necessary to become agile
    4. Gemba and Kaizen become standard practices.
    Organizational Design:
    1. Abandon functional silos for cross-functional teams
    2. Remove redundant middle management layers (Flatten the hierarchy)
    3. No more command & control, compliance-driven management
    4. HR aligns with requirements forf self-organizing teams
    5. The organization morphs into a team of teams
    Clear objectives:
    1. Shared vision among all actors
    2. Clear strategy
    3. Clear priorities
    Business value focus:
    1. Customer centricity mindset
    2. Delivering business results
    3. Shifting the IT focus business needs
    4. From project budgets to product teams.
    Technical Excellence Engineering level:
    1. Built-in quality:
    • Code reviews,
    • TDD (Test automation, test coverage)

  • Pair and mob programming
  • Practicing Scrum, Kanban, XP.
  • Process level:
    1. DevOps: CI, CD (Deployment at will)
    2. Regular cadence of releases
    3. Identifying suitable metrics:
    • Lead time, cycle time,
    • Number of experiments,
    • Team health

  • Open sourcing code.
  • Communication & Collaboration Trust & respect:
    1. Benefit of the doubt for colleagues
    2. Safety to disagree
    3. Honesty
    4. Candid peer feedback.
    Conflict resolution:
    1. Constructive disagreement (Disgree, but commit approach.)
    2. Non-violent communication.
    Collaboration:
    1. Zero tolerance for political games
    2. No scripted collaboration
    3. No incentives to withhold knowledge (Or information.)
    4. No finger-pointing, no blame-game.
    5. How to #Measure #Agility of Organizations and Teams—The Results of the Agile Maturity Survey
      Click To Tweet
      How to Measure Agility of Organizations and Teams—The Conclusion

      Measuring elements of agility at an organizational or team level is nothing new. This ‘agility assessment framework’ approach, however, is new as it aims to be the first open-source and thus widely available tool for all agile practitioners. It is unlikely that the first planned workshop will deliver more than a rudimentary prototype of the agility assessment framework.

      However, it will be a start to gather more insights by applying the framework to real-life work situations and take it from there. Hopefully, we will be able to establish a community around the ‘agility assessment framework’ in the future.

      Do Not Miss Out: Join the 2,300-plus Strong ‘Hands-on Agile’ Slack Team

      I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

      If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

      The post How to Measure Agility of Organizations and Teams—The Results of the Agile Maturity Survey appeared first on Age of Product.

    Read Full Article
    Visit website
    • Show original
    • .
    • Share
    • .
    • Favorite
    • .
    • Email
    • .
    • Add Tags 

    Separate tags by commas
    To access this feature, please upgrade your account.
    Start your free year
    Free Preview