ARE YOU SEEING AGILITY AT SCALE?   Or just a bigger process?

We understand why it is easier to scale Agile process than results.

Have you crossed the agility threshold?

When your team is working in unison, you unlock a self-reinforcing cycle of value creation and flow.  Scaling agility has the potential to bring systemic flow of value to the enterprise, but we’ve rarely seen the same breakthroughs at scale we often see with teams.

Learn How

Breaking through to agility

Agile unleashes the power of cooperation. Organizations that enable true systemic flow of value create cutting-edge breakthroughs in innovation, efficiency, and tap into the passions and talents of a thriving workforce.

How We Do It

Does that look like agility in your enterprise?

Or is it more like a set of gears, ropes and pulleys, less about people, innovation and excellence than about big processes and roles? When was the last time you witnessed cooperation and innovation generating rapid value outside the boundaries of individual teams?

Do you see true agility across and between teams, stakeholders and related organizations?

We can relate.

After watching agility plateau at client after client, we decided to go back to the roots of what made Agile so successful in the first place, and find the missing pieces that prevent agility from scaling.

Get Back to Agile Roots

We found what's been missing.

Using an Integral approach to Agile we discovered we can systematically reveal and remove the hidden barriers that block the breakthrough potential of agility at scale. Our approach focuses on the science of transformation itself, and works independently or alongside your existing approach to scaling Agile.

We're here to help. Click to speak with one of our Integral Agile specialists

 

Integral Agile Inc., is a Minority Certified Business.

Notable clients include:

Read the Latest on How to Navigate the New Business Landscape

Capacity planning: Are you doing it right? Check yes, or no.

Capacity Planning is not hard!

Posted: Monday, November 21, 2022

By: leor

I had a Scrum Master I was mentoring a while back tell me she was off to a meeting about capacity planning with her Release Train Engineer (it was a SAFe environment) and she was nervous because there was disagreement about how they should handle it, and tensions had begun to rise. I was immediately confused - why should such a simple topic be fodder for a cantankerous discussion? I gave her a simple method for establishing her team’s capacity for the next quarter, told her to relax, and sent her to the wolves.

 

Read More

Sometimes you have to break the rules

Posted: Monday, October 31, 2022

By: David Hersey

As I mentioned in a previous post,  Agile was started by a widespread group of individuals who saw the way things were and weren't working and began to creatively break the rules to get better results.

Of course, Agile has grown in the decades since. It’s started to resemble a detailed set of rules for achieving consistent practices and processes across increasingly large sections of organizations. So now it's not uncommon to hear people telling teams or individuals that what you're doing is not following the rules of Agile and in many cases, that's a bad thing. There is value in having consistency. And a common language and intersecting processes when you try to bring Agile to a larger group such as a Team of Teams.

Read More

Overcoming Resistance the Integral Way – Team level

Posted: Monday, October 17, 2022

By: David Hersey

If you are a scrum master or team coach, you’ve probably felt the frustration of laying out a sound set of Agile practices only to find team members lack your enthusiasm for diving in.  With some people, it’s overt – questioning, challenging, complaining about the time spent planning vs coding; in others it’s more subtle – they go through the motions but don’t bring their full selves.  They remain silent in planning and retrospectives, and give perfunctory updates in standups.  Task estimates are more the CYA type, and in general they put as much energy as they can into maintaining the old ways in the new container.  As a coach I’ve seen this across all roles – developers, analysts, testers, even scrum masters.

Read More

Scaled Agility or Big Process?

Posted: Tuesday, July 20, 2021

By: David Hersey

Crossing the threshold of agility

I remember the first time I experienced a team crossing that subtle threshold of discovering the power of working together as a group, with transparency and trust, rather than a collection of individuals working alone on a common project.  I recall the energy that was unlocked as people gradually let go of self-protection, being “right” and began to freely share ideas and concerns, ask hard questions and help each other work out the answers.  As throughput climbed and customer excitement became palpable, as a scrum master I was able to sit back and watch the team literally self-organize, run itself and allow me to guide, support, advocate, remove obstacles and empower them to fly higher and farther than they ever thought possible. 

Read More

What is a Sprint Demo?

What is a Sprint Demo?

Posted: Friday, July 9, 2021

By: Alanna Finn

The Sprint Demo should be the most exciting meeting on any team’s calendar. Why? Because it is the team’s chance to showcase and celebrate all the hard work they accomplished over the course of a sprint.

Traditionally, the Sprint Demo happens at the end of each sprint with the development team, scrum master and product owner, plus anyone who would be interested in the team’s progress, such as customers and stakeholders.

During the Sprint Demo, the team demonstrates what they built- typically working, usable software- to get feedback on what they have built so far, demonstrate progress of the build, and gain insight into how they will continue their work in the next sprint based on input, feedback and questions from the meeting.

Read More

Increasing Collaboration and Trust in any Kind of Team

Posted: Thursday, June 7, 2018

By: leor

We’ve all had the experience of being in a group where everything is flowing really well, people are aligned, and everyone’s energy is high. Then one person says or does something that seems to pop the bubble, and the flow of good ideas stops. The typical response in these situations is a kind of uncomfortable silence followed by a disinterested push to get back to the topic at hand. Everyone in the room can sense that something is different but few are aware of what happened, and almost nobody is aware of the actual phenomenon at work. What follows will be a departure from the typical ideas and style of discourse usually found in a business environment, but it's important to note that most new ideas about how people communicate and behave take a very long time to become accepted in corporate cultures. Those with the courage to adopt cutting edge ideas early stand to gain great competitive advantage.

Read More

Why Agile?

Posted: Tuesday, May 2, 2017

By: leor

Why do we do anything at all? What motivates us to get up in the morning, and come to work? When you think about it, the morning rituals we go through to arrive at a set location at a particular time, with a bunch of other people who feel just like we do (in their own way) in order to do a series of activities most of us could frankly care less about if we weren’t being paid to, does not lend itself to model that results in a happy, engaged workforce where the focus is on the Team more than the Individual.

Read More

WHAT IS INTEGRAL AGILE?

Posted: Monday, March 6, 2017

By: leor

Anyone who has created a truly Agile result at any level of any organization can speak to the elegance of how everything fits together, how information flows, and the way in which actions taken at the smallest task level both impact and are directly informed by everything taking place at larger or higher levels. The most seasoned Agile practitioners will (if they’re being honest) tell you that these “uber” results are very few and far between, but when they happen, there is an elation that seems to roll through everyone involved, that is difficult to express or quantify. They might attribute it to having been a part of a successful initiative, or the feeling of being on a great team, or actually being properly acknowledged for their hard work, and while those things are certainly true, they are not the whole story.

Read More

Measuring Actual Business Value Delivered

Posted: Sunday, March 5, 2017

By: leor

The most accurate way to measure the success of any Agile team, is by validating the actual Business Value delivered with the delivery of working software, and measuring performance based on your Key Performance Metrics to see whether your product is performing to expectations. This is something we call a Long , or Customer Feedback Loop. However, it takes a very long time to envision, design, code, test, and release software into the marketplace, not to mention establishing a user base to observe the performance of your product. While that is an absolutely necessary practice to validate the value proposition of any given product and to take advantage of unforeseen opportunities in customer usage patterns, there are methods that don’t require going all the way to market before getting feedback regarding how much value has been delivered.

Read More

Estimating the Business Value of Stories

Posted: Thursday, January 5, 2017

By: leor

The business value of a product is defined by the product owner as part of the process of developing the product vision and initial product roadmap.

Business value is very specific to the type of product being developed but examples may include:

  • Increasing customer satisfaction
  • Reducing cost and risk in the supply chain
  • Attracting and retaining top talent
  • Customer acquisition
  • Revenue generation

A key principal of agile is maximizing the delivery of business value in every sprint, and estimating the potential business value delivered in a story helps prioritize stories to deliver that maximum value.

Read More

What is VALUE?

Posted: Saturday, December 10, 2016

By: leor

This next series of posts will talk about what  we mean by “Value,” and how we know whether we are delivering it.

If you ask anyone you work with if they think they are delivering value to the business or to their product, they will most likely say “yes” (if they say “no” you probably have an interesting conversation ahead, stick with it!). If you were to ask them what they thought delivering value meant, they would probably tell you about the many activities they perform throughout the day, but how do we know whether they are valuable?

Read More

The wisdom of Monty Python

Posted: Sunday, October 9, 2016

By: leor

Monty Python gives so much we can use in our transformation strategy!

Strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not some farcical aquatic ceremony! – Servant Leaders

 

You think you’ve had a hard time? I’ve been chained to the wall for five years, and they only hung me the right way up yesterday! - Retrospectives

 

Read More

The Role of an Agile Coach

Posted: Saturday, September 10, 2016

By: leor

“Our team is going Agile,” “where are you on your Agile journey,” and “what is the most important Agile metric,” might be some things you’ve heard or thought about lately. The answers to these and the many other questions or descriptions I’ve heard in my adventures across the enterprise have been at times confusing, at times contradictory, and sometimes even quite amusing. In an enterprise this big, with the many different kinds of products and objectives, different organizations, different types of problems to solve, and the adaptability of the many Agile frameworks, it’s not surprising that interpretations and perceptions could vary, sometimes wildly. Enter: The Agile Coach. What does an Agile Coach do? Agile coaches are subject matter experts with broad experience across many different companies and industries.

Read More

What is a Definition of DONE, and why do we need one?

Posted: Monday, August 8, 2016

By: leor

The goal of the Definition of DONE agreement is many fold, and it exists not only to create a standard by which teams can operate so that they can feel confident that when someone says, “I’m DONE!” they know precisely what that means, but also to ensure that all involved stakeholders understand when, why, and how to engage with a given team, and what they can expect from their contributions. There are 3 typical stages to a standard DoD template, while they may be described in different ways, an easy way to think about it might be, “to whom is this most relevant?” These also map to specific states in Rally, and can be informative if you’re using Scrum, and serve as exit criteria if you’re using Kanban. What follows should be tweaked to be specific to your team and your partners.

COMPLETED -  I’m DONE! (Developer’s perspective)

Read More

SPRINT/ITERATION REVIEW

Posted: Friday, July 8, 2016

By: leor

In order for the team to review the work done in the previous Sprint/Iteration, a Sprint/Iteration Review is held. Note that this is not the occasion for the team to present the work to the Product Owner.

This Review meeting should be scheduled for the first available time slot after the end of the previous Sprint/Iteration and last 30 minutes for a single team, or up to 30 minutes per team for multiple teams in a single program. It is common for teams to schedule the first 30 minutes of their Sprint Planning meeting to review the previous Sprint.

The predecessors to the Sprint/Iteration Review is that all previous Sprint/Iteration activities are completed and updated in your agile tool of choice, the whole team including influencers and dependents are invited to the meeting, and all code is checked-in and built into an environment/sandbox different from the development environments.

Read More

THE SPRINT DEMO

Posted: Sunday, June 5, 2016

By: leor

At the end of each Sprint/Iteration, a Demo meeting is held where the Team shows what they accomplished during the past 2 weeks. Given that Agile is an empirical process, and the goal of every Sprint is to product Potentially Shippable Software, only work that meets the Definition of DONE is demonstrated at the end of the Sprint. The Demo usually consists of the development team, the Scrum Master, the Product Owner, but is essentially an open meeting, and all stakeholders, leaders, and interested parties are invited and encouraged to join to observe the team’s progress.

The Demo serves many purposes, as follows

Read More

SPRINT/ITERATION PLANNING

Posted: Saturday, May 7, 2016

By: leor

The purpose of Sprint/Iteration Planning is for a team to identify and commit to the total amount of work they think they can to accomplish within a 2 week period. In order to have a successful Sprint Planning meeting, there needs to be an organized, prioritized backlog with a sufficient amount of stories in a READY state for the team to pick up and complete within the iteration. A typical Sprint Planning meeting proceeds as follows.

Read More

BEST PRACTICES FOR DEFINING USER STORIES

Posted: Tuesday, April 5, 2016

By: leor

Many new agile teams attempt to create stories by architectural layer: one story for the UI, another for the database, etc. This may satisfy Small requirement, but it fails at Independent and Valuable (as part of the Bill Wake’s INVEST model).

Typically, large User Stories can be split using several of patterns. Here are two general rules of thumb in determining the right split to make:

Read More

USER STORIES

Posted: Saturday, March 5, 2016

By: leor

These next couple of posts will take things down to the most basic of Agile requirements: the User Story. A User Story is a tool used in the Agile development methodology to capture a description of functionality from an end-user perspective. The user story describes the type of user, what they want and why. It helps to create a simplified description of a software requirement.

User Story is a brief statement of intent that describes something the system needs to do for the user. We write them to relate business objectives and value:

As a <type of user> I want <some goal> so that <some reason> As a <user> I want <objective> so that I can <benefit>

Read More

Empirical Management

Posted: Sunday, February 14, 2016

By: leor

Aliases: Adaptive Management …

Your company has been using a traditional approach to management of engineering projects. Now, senior management wants to change how they manage and execute projects so that they can better deliver software – faster and cheaper.

???

A number of organizations use traditional approaches (Linear Sequential Model or Waterfall based processes) for software development. Post funding approval, such processes begin with an obligatory requirements gathering phase followed by an analysis and design phase, a detailed design phase, development, system integration, user acceptance, and production deployment.

Traditional approaches consider obligatory that all requirements be gathered at the start of a project. Managers in such organizations implicitly assume that:

Read More

Teaching to the Test

Posted: Monday, December 14, 2015

By: leor

by Bill Rinko-Gay

This blog is a follow-on to the post entitled “Open Book Testing.” If you haven’t already, you may want to read that first.

Once you have reviewed all your test stories it’s time to prepare to execute them. A well planned test execution, in conjunction with a well planned code implementation, helps to actually build quality in as well as verify the quality of the completed software.

Read More

Open Book Testing

Posted: Wednesday, November 11, 2015

By: leor

by Bill Rinko-Gay

There are two components of quality software: building the right thing and building the thing right. One of the most difficult things to get right is knowing what the right thing is. In non-Agile methods this puts the focus on defining complete and detailed requirements. Experience shows that it is very difficult, if not impossible, to specify exactly what you want when you haven’t seen or worked with it yet.

In the absence of complete and detailed requirements we have to build software with a knowledge of what that software must do to satisfy the user. This knowledge has to be shared by the entire Agile team. We start to share this knowledge with a user story, but that only gives part of the picture. The rest of the picture is given in implementation and test plans.

Read More

Agile Quality Assurance

Posted: Wednesday, September 30, 2015

By: leor

by Bill Rinko-Gay

When I first started researching Agile Quality Assurance I was told it wasn’t necessary because Agile methods have quality built in. Agile teams developed processes such as Extreme Programming (XP) and Test Driven Development (TDD) to produce quality code in a short amount of time. Because these processes work well, it is believed Agile teams don’t need Quality Assurance. I disagree. I have studied and implemented Agile methods based on over 28 years of practical test and quality assurance experience. My viewpoint gives me a different perspective on Agile and Quality Assurance.

Read More

Software Development is not Manufacturing

Posted: Wednesday, August 5, 2015

By: leor

Software Development is Not Manufacturing

… Your company likens software development to a production (manufacturing) environment and expects people and processes to reflect the same.

???

A number of organizations use Waterfall based processes for software development that call for all requirements to be gathered at the start of a project.

Software project managers and delivery departments (IT) are often evaluated on how well they meet the budgetary and schedule constraints while delivering the agreed to scope. Variations are frowned upon and delays are attributed to poor planning — if the team had done a good job in anticipating and planning, the team would not have been surprised in the middle of the project, and would have delivered on time. To get better, then, the bias is to try and drive out the variation by doing more rigorous up-front planning.

Read More

Team Metrics

Posted: Tuesday, June 30, 2015

By: leor

Team Metrics

  • How fast are we going?
  • What’s our biggest obstacle to velocity?
  • Does we have enough requirements defined?
  • Are we building the most valuable things we can?
  • Is there something we’re deferring that should be worked on now?
  • Are we getting things all the way done?
  • What would we have if we had to ship tomorrow?

These are questions Agile team members ask every sprint. When a team does a retrospective, the answers to these can be very subjective. The right set of lightweight metrics provides objective, results-driven feedback that focuses the discussion on areas of highest impact.

Feedback and Management Tools

Here is a set of lightweight metrics that can be easily derived from information captured in project tracking tools such as Rally, Jira, or VersionOne.

Read More

Management Metrics

Posted: Monday, May 4, 2015

By: leor

  • Are we tracking to the business case?
  • How much time & cost remain to complete the project?
  • Are we over or under budget?
  • How can I give my customer even more value?
  • What will I have ready to ship & when?

These are questions project and program managers ask every sprint. On Agile projects, the answers are based on the team’s historical achievements and projected forward using recent results. This leads to greater and greater confidence in the information as the project moves towards release dates, and enables the manager to communicate a roadmap with high confidence of delivering what is promised.

The Agile Product Dashboard

Read More

Book Content and Layout

Posted: Monday, March 2, 2015

By: leor

As mentioned previously, this blog series will cover the basic patterns only; advanced topics may be addressed in the future.

I will cover the basics on the principles and process before discussing the team and technical practices. Lean Software Development will be covered subsequently. The following topics will be covered in the order (more or less) listed below:

  1. Agile Principles
  2. Iteration Planning
  3. Requirements Management
  4. Estimation
  5. Quality
  6. Communication and Visibility
  7. Team Roles and Organization
  8. Technical Practices
  9. Lean Practices

Tomorrow, we start with the first pattern in the Agile Principles section.

Read More

Efficient Dev-Test

Posted: Saturday, February 21, 2015

By: leor

by Bill Rinko-Gay

One of the advantages of Agile is the ability to deliver continuous improvements to your customer. If you have experience in traditional development paradigms you a release is usually a mixed bag filled with new functionality and new (and sometimes old) defects. This is frustrating for users and the development team. You seem to always be under a backlog of bugs that keeps the software from delivering all the business value you intended.

This constant backlog doesn’t just occur in traditional development, it can occur on Agile projects as well. The hurry to try to reduce the backlog by fixing last-minute bugs leads to thrash, and thrash can lead to reduced quality as hurry cause the team to introduce new bugs. Your goal is to move always forward with your code, but the reality is often “two steps forward, one step back.”

Read More

Alexandrian Pattern Format

Posted: Thursday, February 19, 2015

By: leor

Pattern Name*** (with confidence level)

Aliases: if any …

Context in which we find the problem

The context is often described via a “situation” rather than stated explicitly. Sometimes, the context is described in terms of the patterns that have already been applied.

???

Forces or trade-offs behind the pattern

The often contradictory considerations that must be taken into account when choosing a solution to a problem. The relative importance of the forces (those that need to be optimized at the expense of others) is implied by the context.

Read More

Functional Grouping

Posted: Wednesday, January 28, 2015

By: leor

by Bill Rinko-Gay

Now that your stories are chosen and the iteration has been kicked off, is there any reason not to have developers simply start in as quickly as they can on writing the code for the stories? I believe there are 3 reasons to set up a plan for delivering groups of stories to test. First, functional grouping allows for higher quality code delivered faster. Second, functional grouping makes the testing job far easier. Third, functional grouping allows the team to re-plan an incomplete iteration. Let’s look at each of these claims in detail.

Read More

Upcoming Agile Patterns Book Online

Posted: Tuesday, January 13, 2015

By: leor

Recently I was interviewing candidates for a couple of positions on an Agile project. As part of the recruiting process, I had to spend considerable time (aka late nights) going through dozens and dozens of resumes in order to shortlist the ones that seemed promising enough to call for a face-to-face interview.

While going through the resumes, I realized that the more resumes I went through, the more impatient I kept getting. I soon realized that each and every resume mentioned at least once that the person had done a project in an Agile manner. However, there was nothing further to back this up anywhere. It seemed like people were gratuitously dropping the term so that their resume would be picked-up when a keyword search was done.

Read More

A Note on Patterns

Posted: Tuesday, December 16, 2014

By: leor

Patterns organize implicit knowledge about how people successfully solve recurring problems. Patterns describe solutions that have been successfully applied on numerous occasions; they are not theoretical abstractions created in ivory towers.

Christopher Alexander defines a pattern as follows: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” (Alexander, 1997, A Pattern Language)

Read More

Agile performance: it's about more than skills!

Posted: Saturday, November 1, 2014

By: leor

What makes a successful Agile team member?

I’ve been asked this question numerous times by people assembling a Scrum or XP team, so I thought I would blog about it. Simply put, attitude is everything.

Sure, you need to be competent at the right technical skills, but I will take 1 person with the right attitude and acceptable skills over 3 technical experts who do not exhibit the right attitudinal traits, every time. And I’ll get more value out of the average guy with the right attitude than I would out of the experts. In fact, I’d put money down that by the end of my project the so-called average guy will be performing at an expert level.

Agile methods value “People over process” and rely on people to come together as a team, self-organize, and be focused on the group result rather than their own individual skills to determine their success.

Read More

Welcome to Agile People Patterns

Posted: Saturday, September 6, 2014

By: leor

In this series of posts, I will discuss common (and not so-common) problems faced by teams and their leadership trying to adopt Agile practices.

Adopting Agile is a lot harder than practicing Agile! If you have had the privilege of observing a mature Scrum team, you can see how effortlessly individuals come together so that the team rapidly delivers value. Work flows smoothly, with components being developed, dependencies resolved, designs agreed on and frequent deployments occurring with a only brief ad-hoc conversations needed to coordinate between team members.

Read More

Tapping the power of Scrum for your organization

Posted: Friday, July 25, 2014

By: leor

Thesis: agile methods can save you money. Are you getting your share? Systematic adoption of agile methods can substantially reduce your project costs; however it can be hard to get these results right away. Most new agile teams don’t see these results until the 3rd or subsequent project. That’s where we come in.

We can give you the benefits you expect on your first project, by running your first project and training your team. Think of us a training wheels for your team as you bring Agile into your group. Using a set of scalable, lightweight agile practices from SCRUM and other agile methods, we will run your first project and train your team on-the-job where results are immediately visible, not in a classroom. We use a clear and comprehensive measurement system to demonstrate rapid progress to both the team and management. You’ll see your costs dropping month by month!

Read More

Why is my team slowing down?

Posted: Friday, June 20, 2014

By: leor

The worst thing any team can do is to raise expectations through early success, but be unable to sustain the pace. This happens to many Agile teams due to some simple mistakes made in tracking Team Velocity. As a result of these painful misses, some organizations are getting a bad taste for Agile, and are once again looking to the next big idea to get the performance they want.

Let’s look at the formula for velocity: Velocity = Story Points Accepted/1 sprint

Pitfall #1: Story Points Accepted.

The way a team determines whether a User Story is accepted is important. If a team does not have a strong Definition of Done it is likely to inadvertently count stories as Accepted (and therefore part of velocity) when in fact they may still need work such as complying with code standards, including logging & exception handling, fixing defects or even handling minor requirements that fell off the table during the sprint.

Read More

Agile velocity

Posted: Monday, April 7, 2014

By: leor

Velocity is the primary measure of the performance of an Agile team.

The Agile manifesto values “Finished Software” as the primary deliverable of a team, and team velocity is an agile metric that measures that directly.

Measuring Team Velocity:

  • The previous article defines Agile success as:
  • The team’s ability to plan and complete a set of stories within a sprint, have the work accepted by the business owner, technical reviewer(s) and have zero defects carried over in to the next sprint.

Velocity measures a team’s capacity to do this, by counting Story Points of the stories that are accepted during each sprint. Over time, as a team gets more productive, the team is able to design, code, test and accept more Story Points in a sprint and the Team Velocity rises.

Read More

Welcome to Agile by the Numbers

Posted: Monday, February 3, 2014

By: leor

This series of articles delves into the sticky topic of Agile metrics. Let me state right off the bat that this is NOT focused on measuring the performance of an Agile team for purposes of benchmarking or report-card scoring, although you will get some nice data for this purpose if you follow along.

The main purpose of Agile by the Numbers is to put a small number of key sensors in place, to create information for the Agile team to see where they are headed and where they can focus to improve their success.

I prefer the term “sensor” to “metric” because I believe that the purpose of any measurement is to improve a team’s ability to sense and respond to issues affecting their success. Metrics, on the other hand, tend to be more management-focused and frequently do not deliver this type of value at the team level.

Read More

Read the Latest on How to Navigate the New Business Landscape

Capacity planning: Are you doing it right? Check yes, or no.

Capacity Planning is not hard!

Posted: Monday, November 21, 2022

By: leor

I had a Scrum Master I was mentoring a while back tell me she was off to a meeting about capacity planning with her Release Train Engineer (it was a SAFe environment) and she was nervous because there was disagreement about how they should handle it, and tensions had begun to rise. I was immediately confused - why should such a simple topic be fodder for a cantankerous discussion? I gave her a simple method for establishing her team’s capacity for the next quarter, told her to relax, and sent her to the wolves.

 

Read More

Sometimes you have to break the rules

Posted: Monday, October 31, 2022

By: David Hersey

As I mentioned in a previous post,  Agile was started by a widespread group of individuals who saw the way things were and weren't working and began to creatively break the rules to get better results.

Of course, Agile has grown in the decades since. It’s started to resemble a detailed set of rules for achieving consistent practices and processes across increasingly large sections of organizations. So now it's not uncommon to hear people telling teams or individuals that what you're doing is not following the rules of Agile and in many cases, that's a bad thing. There is value in having consistency. And a common language and intersecting processes when you try to bring Agile to a larger group such as a Team of Teams.

Read More

Overcoming Resistance the Integral Way – Team level

Posted: Monday, October 17, 2022

By: David Hersey

If you are a scrum master or team coach, you’ve probably felt the frustration of laying out a sound set of Agile practices only to find team members lack your enthusiasm for diving in.  With some people, it’s overt – questioning, challenging, complaining about the time spent planning vs coding; in others it’s more subtle – they go through the motions but don’t bring their full selves.  They remain silent in planning and retrospectives, and give perfunctory updates in standups.  Task estimates are more the CYA type, and in general they put as much energy as they can into maintaining the old ways in the new container.  As a coach I’ve seen this across all roles – developers, analysts, testers, even scrum masters.

Read More

Scaled Agility or Big Process?

Posted: Tuesday, July 20, 2021

By: David Hersey

Crossing the threshold of agility

I remember the first time I experienced a team crossing that subtle threshold of discovering the power of working together as a group, with transparency and trust, rather than a collection of individuals working alone on a common project.  I recall the energy that was unlocked as people gradually let go of self-protection, being “right” and began to freely share ideas and concerns, ask hard questions and help each other work out the answers.  As throughput climbed and customer excitement became palpable, as a scrum master I was able to sit back and watch the team literally self-organize, run itself and allow me to guide, support, advocate, remove obstacles and empower them to fly higher and farther than they ever thought possible. 

Read More

What is a Sprint Demo?

What is a Sprint Demo?

Posted: Friday, July 9, 2021

By: Alanna Finn

The Sprint Demo should be the most exciting meeting on any team’s calendar. Why? Because it is the team’s chance to showcase and celebrate all the hard work they accomplished over the course of a sprint.

Traditionally, the Sprint Demo happens at the end of each sprint with the development team, scrum master and product owner, plus anyone who would be interested in the team’s progress, such as customers and stakeholders.

During the Sprint Demo, the team demonstrates what they built- typically working, usable software- to get feedback on what they have built so far, demonstrate progress of the build, and gain insight into how they will continue their work in the next sprint based on input, feedback and questions from the meeting.

Read More

Increasing Collaboration and Trust in any Kind of Team

Posted: Thursday, June 7, 2018

By: leor

We’ve all had the experience of being in a group where everything is flowing really well, people are aligned, and everyone’s energy is high. Then one person says or does something that seems to pop the bubble, and the flow of good ideas stops. The typical response in these situations is a kind of uncomfortable silence followed by a disinterested push to get back to the topic at hand. Everyone in the room can sense that something is different but few are aware of what happened, and almost nobody is aware of the actual phenomenon at work. What follows will be a departure from the typical ideas and style of discourse usually found in a business environment, but it's important to note that most new ideas about how people communicate and behave take a very long time to become accepted in corporate cultures. Those with the courage to adopt cutting edge ideas early stand to gain great competitive advantage.

Read More

Why Agile?

Posted: Tuesday, May 2, 2017

By: leor

Why do we do anything at all? What motivates us to get up in the morning, and come to work? When you think about it, the morning rituals we go through to arrive at a set location at a particular time, with a bunch of other people who feel just like we do (in their own way) in order to do a series of activities most of us could frankly care less about if we weren’t being paid to, does not lend itself to model that results in a happy, engaged workforce where the focus is on the Team more than the Individual.

Read More

WHAT IS INTEGRAL AGILE?

Posted: Monday, March 6, 2017

By: leor

Anyone who has created a truly Agile result at any level of any organization can speak to the elegance of how everything fits together, how information flows, and the way in which actions taken at the smallest task level both impact and are directly informed by everything taking place at larger or higher levels. The most seasoned Agile practitioners will (if they’re being honest) tell you that these “uber” results are very few and far between, but when they happen, there is an elation that seems to roll through everyone involved, that is difficult to express or quantify. They might attribute it to having been a part of a successful initiative, or the feeling of being on a great team, or actually being properly acknowledged for their hard work, and while those things are certainly true, they are not the whole story.

Read More

Measuring Actual Business Value Delivered

Posted: Sunday, March 5, 2017

By: leor

The most accurate way to measure the success of any Agile team, is by validating the actual Business Value delivered with the delivery of working software, and measuring performance based on your Key Performance Metrics to see whether your product is performing to expectations. This is something we call a Long , or Customer Feedback Loop. However, it takes a very long time to envision, design, code, test, and release software into the marketplace, not to mention establishing a user base to observe the performance of your product. While that is an absolutely necessary practice to validate the value proposition of any given product and to take advantage of unforeseen opportunities in customer usage patterns, there are methods that don’t require going all the way to market before getting feedback regarding how much value has been delivered.

Read More

Estimating the Business Value of Stories

Posted: Thursday, January 5, 2017

By: leor

The business value of a product is defined by the product owner as part of the process of developing the product vision and initial product roadmap.

Business value is very specific to the type of product being developed but examples may include:

  • Increasing customer satisfaction
  • Reducing cost and risk in the supply chain
  • Attracting and retaining top talent
  • Customer acquisition
  • Revenue generation

A key principal of agile is maximizing the delivery of business value in every sprint, and estimating the potential business value delivered in a story helps prioritize stories to deliver that maximum value.

Read More

What is VALUE?

Posted: Saturday, December 10, 2016

By: leor

This next series of posts will talk about what  we mean by “Value,” and how we know whether we are delivering it.

If you ask anyone you work with if they think they are delivering value to the business or to their product, they will most likely say “yes” (if they say “no” you probably have an interesting conversation ahead, stick with it!). If you were to ask them what they thought delivering value meant, they would probably tell you about the many activities they perform throughout the day, but how do we know whether they are valuable?

Read More

The wisdom of Monty Python

Posted: Sunday, October 9, 2016

By: leor

Monty Python gives so much we can use in our transformation strategy!

Strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not some farcical aquatic ceremony! – Servant Leaders

 

You think you’ve had a hard time? I’ve been chained to the wall for five years, and they only hung me the right way up yesterday! - Retrospectives

 

Read More

The Role of an Agile Coach

Posted: Saturday, September 10, 2016

By: leor

“Our team is going Agile,” “where are you on your Agile journey,” and “what is the most important Agile metric,” might be some things you’ve heard or thought about lately. The answers to these and the many other questions or descriptions I’ve heard in my adventures across the enterprise have been at times confusing, at times contradictory, and sometimes even quite amusing. In an enterprise this big, with the many different kinds of products and objectives, different organizations, different types of problems to solve, and the adaptability of the many Agile frameworks, it’s not surprising that interpretations and perceptions could vary, sometimes wildly. Enter: The Agile Coach. What does an Agile Coach do? Agile coaches are subject matter experts with broad experience across many different companies and industries.

Read More

What is a Definition of DONE, and why do we need one?

Posted: Monday, August 8, 2016

By: leor

The goal of the Definition of DONE agreement is many fold, and it exists not only to create a standard by which teams can operate so that they can feel confident that when someone says, “I’m DONE!” they know precisely what that means, but also to ensure that all involved stakeholders understand when, why, and how to engage with a given team, and what they can expect from their contributions. There are 3 typical stages to a standard DoD template, while they may be described in different ways, an easy way to think about it might be, “to whom is this most relevant?” These also map to specific states in Rally, and can be informative if you’re using Scrum, and serve as exit criteria if you’re using Kanban. What follows should be tweaked to be specific to your team and your partners.

COMPLETED -  I’m DONE! (Developer’s perspective)

Read More

SPRINT/ITERATION REVIEW

Posted: Friday, July 8, 2016

By: leor

In order for the team to review the work done in the previous Sprint/Iteration, a Sprint/Iteration Review is held. Note that this is not the occasion for the team to present the work to the Product Owner.

This Review meeting should be scheduled for the first available time slot after the end of the previous Sprint/Iteration and last 30 minutes for a single team, or up to 30 minutes per team for multiple teams in a single program. It is common for teams to schedule the first 30 minutes of their Sprint Planning meeting to review the previous Sprint.

The predecessors to the Sprint/Iteration Review is that all previous Sprint/Iteration activities are completed and updated in your agile tool of choice, the whole team including influencers and dependents are invited to the meeting, and all code is checked-in and built into an environment/sandbox different from the development environments.

Read More

THE SPRINT DEMO

Posted: Sunday, June 5, 2016

By: leor

At the end of each Sprint/Iteration, a Demo meeting is held where the Team shows what they accomplished during the past 2 weeks. Given that Agile is an empirical process, and the goal of every Sprint is to product Potentially Shippable Software, only work that meets the Definition of DONE is demonstrated at the end of the Sprint. The Demo usually consists of the development team, the Scrum Master, the Product Owner, but is essentially an open meeting, and all stakeholders, leaders, and interested parties are invited and encouraged to join to observe the team’s progress.

The Demo serves many purposes, as follows

Read More

SPRINT/ITERATION PLANNING

Posted: Saturday, May 7, 2016

By: leor

The purpose of Sprint/Iteration Planning is for a team to identify and commit to the total amount of work they think they can to accomplish within a 2 week period. In order to have a successful Sprint Planning meeting, there needs to be an organized, prioritized backlog with a sufficient amount of stories in a READY state for the team to pick up and complete within the iteration. A typical Sprint Planning meeting proceeds as follows.

Read More

BEST PRACTICES FOR DEFINING USER STORIES

Posted: Tuesday, April 5, 2016

By: leor

Many new agile teams attempt to create stories by architectural layer: one story for the UI, another for the database, etc. This may satisfy Small requirement, but it fails at Independent and Valuable (as part of the Bill Wake’s INVEST model).

Typically, large User Stories can be split using several of patterns. Here are two general rules of thumb in determining the right split to make:

Read More

USER STORIES

Posted: Saturday, March 5, 2016

By: leor

These next couple of posts will take things down to the most basic of Agile requirements: the User Story. A User Story is a tool used in the Agile development methodology to capture a description of functionality from an end-user perspective. The user story describes the type of user, what they want and why. It helps to create a simplified description of a software requirement.

User Story is a brief statement of intent that describes something the system needs to do for the user. We write them to relate business objectives and value:

As a <type of user> I want <some goal> so that <some reason> As a <user> I want <objective> so that I can <benefit>

Read More

Empirical Management

Posted: Sunday, February 14, 2016

By: leor

Aliases: Adaptive Management …

Your company has been using a traditional approach to management of engineering projects. Now, senior management wants to change how they manage and execute projects so that they can better deliver software – faster and cheaper.

???

A number of organizations use traditional approaches (Linear Sequential Model or Waterfall based processes) for software development. Post funding approval, such processes begin with an obligatory requirements gathering phase followed by an analysis and design phase, a detailed design phase, development, system integration, user acceptance, and production deployment.

Traditional approaches consider obligatory that all requirements be gathered at the start of a project. Managers in such organizations implicitly assume that:

Read More

Teaching to the Test

Posted: Monday, December 14, 2015

By: leor

by Bill Rinko-Gay

This blog is a follow-on to the post entitled “Open Book Testing.” If you haven’t already, you may want to read that first.

Once you have reviewed all your test stories it’s time to prepare to execute them. A well planned test execution, in conjunction with a well planned code implementation, helps to actually build quality in as well as verify the quality of the completed software.

Read More

Open Book Testing

Posted: Wednesday, November 11, 2015

By: leor

by Bill Rinko-Gay

There are two components of quality software: building the right thing and building the thing right. One of the most difficult things to get right is knowing what the right thing is. In non-Agile methods this puts the focus on defining complete and detailed requirements. Experience shows that it is very difficult, if not impossible, to specify exactly what you want when you haven’t seen or worked with it yet.

In the absence of complete and detailed requirements we have to build software with a knowledge of what that software must do to satisfy the user. This knowledge has to be shared by the entire Agile team. We start to share this knowledge with a user story, but that only gives part of the picture. The rest of the picture is given in implementation and test plans.

Read More

Agile Quality Assurance

Posted: Wednesday, September 30, 2015

By: leor

by Bill Rinko-Gay

When I first started researching Agile Quality Assurance I was told it wasn’t necessary because Agile methods have quality built in. Agile teams developed processes such as Extreme Programming (XP) and Test Driven Development (TDD) to produce quality code in a short amount of time. Because these processes work well, it is believed Agile teams don’t need Quality Assurance. I disagree. I have studied and implemented Agile methods based on over 28 years of practical test and quality assurance experience. My viewpoint gives me a different perspective on Agile and Quality Assurance.

Read More

Software Development is not Manufacturing

Posted: Wednesday, August 5, 2015

By: leor

Software Development is Not Manufacturing

… Your company likens software development to a production (manufacturing) environment and expects people and processes to reflect the same.

???

A number of organizations use Waterfall based processes for software development that call for all requirements to be gathered at the start of a project.

Software project managers and delivery departments (IT) are often evaluated on how well they meet the budgetary and schedule constraints while delivering the agreed to scope. Variations are frowned upon and delays are attributed to poor planning — if the team had done a good job in anticipating and planning, the team would not have been surprised in the middle of the project, and would have delivered on time. To get better, then, the bias is to try and drive out the variation by doing more rigorous up-front planning.

Read More

Team Metrics

Posted: Tuesday, June 30, 2015

By: leor

Team Metrics

  • How fast are we going?
  • What’s our biggest obstacle to velocity?
  • Does we have enough requirements defined?
  • Are we building the most valuable things we can?
  • Is there something we’re deferring that should be worked on now?
  • Are we getting things all the way done?
  • What would we have if we had to ship tomorrow?

These are questions Agile team members ask every sprint. When a team does a retrospective, the answers to these can be very subjective. The right set of lightweight metrics provides objective, results-driven feedback that focuses the discussion on areas of highest impact.

Feedback and Management Tools

Here is a set of lightweight metrics that can be easily derived from information captured in project tracking tools such as Rally, Jira, or VersionOne.

Read More

Management Metrics

Posted: Monday, May 4, 2015

By: leor

  • Are we tracking to the business case?
  • How much time & cost remain to complete the project?
  • Are we over or under budget?
  • How can I give my customer even more value?
  • What will I have ready to ship & when?

These are questions project and program managers ask every sprint. On Agile projects, the answers are based on the team’s historical achievements and projected forward using recent results. This leads to greater and greater confidence in the information as the project moves towards release dates, and enables the manager to communicate a roadmap with high confidence of delivering what is promised.

The Agile Product Dashboard

Read More

Book Content and Layout

Posted: Monday, March 2, 2015

By: leor

As mentioned previously, this blog series will cover the basic patterns only; advanced topics may be addressed in the future.

I will cover the basics on the principles and process before discussing the team and technical practices. Lean Software Development will be covered subsequently. The following topics will be covered in the order (more or less) listed below:

  1. Agile Principles
  2. Iteration Planning
  3. Requirements Management
  4. Estimation
  5. Quality
  6. Communication and Visibility
  7. Team Roles and Organization
  8. Technical Practices
  9. Lean Practices

Tomorrow, we start with the first pattern in the Agile Principles section.

Read More

Efficient Dev-Test

Posted: Saturday, February 21, 2015

By: leor

by Bill Rinko-Gay

One of the advantages of Agile is the ability to deliver continuous improvements to your customer. If you have experience in traditional development paradigms you a release is usually a mixed bag filled with new functionality and new (and sometimes old) defects. This is frustrating for users and the development team. You seem to always be under a backlog of bugs that keeps the software from delivering all the business value you intended.

This constant backlog doesn’t just occur in traditional development, it can occur on Agile projects as well. The hurry to try to reduce the backlog by fixing last-minute bugs leads to thrash, and thrash can lead to reduced quality as hurry cause the team to introduce new bugs. Your goal is to move always forward with your code, but the reality is often “two steps forward, one step back.”

Read More

Alexandrian Pattern Format

Posted: Thursday, February 19, 2015

By: leor

Pattern Name*** (with confidence level)

Aliases: if any …

Context in which we find the problem

The context is often described via a “situation” rather than stated explicitly. Sometimes, the context is described in terms of the patterns that have already been applied.

???

Forces or trade-offs behind the pattern

The often contradictory considerations that must be taken into account when choosing a solution to a problem. The relative importance of the forces (those that need to be optimized at the expense of others) is implied by the context.

Read More

Functional Grouping

Posted: Wednesday, January 28, 2015

By: leor

by Bill Rinko-Gay

Now that your stories are chosen and the iteration has been kicked off, is there any reason not to have developers simply start in as quickly as they can on writing the code for the stories? I believe there are 3 reasons to set up a plan for delivering groups of stories to test. First, functional grouping allows for higher quality code delivered faster. Second, functional grouping makes the testing job far easier. Third, functional grouping allows the team to re-plan an incomplete iteration. Let’s look at each of these claims in detail.

Read More

Upcoming Agile Patterns Book Online

Posted: Tuesday, January 13, 2015

By: leor

Recently I was interviewing candidates for a couple of positions on an Agile project. As part of the recruiting process, I had to spend considerable time (aka late nights) going through dozens and dozens of resumes in order to shortlist the ones that seemed promising enough to call for a face-to-face interview.

While going through the resumes, I realized that the more resumes I went through, the more impatient I kept getting. I soon realized that each and every resume mentioned at least once that the person had done a project in an Agile manner. However, there was nothing further to back this up anywhere. It seemed like people were gratuitously dropping the term so that their resume would be picked-up when a keyword search was done.

Read More

A Note on Patterns

Posted: Tuesday, December 16, 2014

By: leor

Patterns organize implicit knowledge about how people successfully solve recurring problems. Patterns describe solutions that have been successfully applied on numerous occasions; they are not theoretical abstractions created in ivory towers.

Christopher Alexander defines a pattern as follows: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” (Alexander, 1997, A Pattern Language)

Read More

Agile performance: it's about more than skills!

Posted: Saturday, November 1, 2014

By: leor

What makes a successful Agile team member?

I’ve been asked this question numerous times by people assembling a Scrum or XP team, so I thought I would blog about it. Simply put, attitude is everything.

Sure, you need to be competent at the right technical skills, but I will take 1 person with the right attitude and acceptable skills over 3 technical experts who do not exhibit the right attitudinal traits, every time. And I’ll get more value out of the average guy with the right attitude than I would out of the experts. In fact, I’d put money down that by the end of my project the so-called average guy will be performing at an expert level.

Agile methods value “People over process” and rely on people to come together as a team, self-organize, and be focused on the group result rather than their own individual skills to determine their success.

Read More

Welcome to Agile People Patterns

Posted: Saturday, September 6, 2014

By: leor

In this series of posts, I will discuss common (and not so-common) problems faced by teams and their leadership trying to adopt Agile practices.

Adopting Agile is a lot harder than practicing Agile! If you have had the privilege of observing a mature Scrum team, you can see how effortlessly individuals come together so that the team rapidly delivers value. Work flows smoothly, with components being developed, dependencies resolved, designs agreed on and frequent deployments occurring with a only brief ad-hoc conversations needed to coordinate between team members.

Read More

Tapping the power of Scrum for your organization

Posted: Friday, July 25, 2014

By: leor

Thesis: agile methods can save you money. Are you getting your share? Systematic adoption of agile methods can substantially reduce your project costs; however it can be hard to get these results right away. Most new agile teams don’t see these results until the 3rd or subsequent project. That’s where we come in.

We can give you the benefits you expect on your first project, by running your first project and training your team. Think of us a training wheels for your team as you bring Agile into your group. Using a set of scalable, lightweight agile practices from SCRUM and other agile methods, we will run your first project and train your team on-the-job where results are immediately visible, not in a classroom. We use a clear and comprehensive measurement system to demonstrate rapid progress to both the team and management. You’ll see your costs dropping month by month!

Read More

Why is my team slowing down?

Posted: Friday, June 20, 2014

By: leor

The worst thing any team can do is to raise expectations through early success, but be unable to sustain the pace. This happens to many Agile teams due to some simple mistakes made in tracking Team Velocity. As a result of these painful misses, some organizations are getting a bad taste for Agile, and are once again looking to the next big idea to get the performance they want.

Let’s look at the formula for velocity: Velocity = Story Points Accepted/1 sprint

Pitfall #1: Story Points Accepted.

The way a team determines whether a User Story is accepted is important. If a team does not have a strong Definition of Done it is likely to inadvertently count stories as Accepted (and therefore part of velocity) when in fact they may still need work such as complying with code standards, including logging & exception handling, fixing defects or even handling minor requirements that fell off the table during the sprint.

Read More

Agile velocity

Posted: Monday, April 7, 2014

By: leor

Velocity is the primary measure of the performance of an Agile team.

The Agile manifesto values “Finished Software” as the primary deliverable of a team, and team velocity is an agile metric that measures that directly.

Measuring Team Velocity:

  • The previous article defines Agile success as:
  • The team’s ability to plan and complete a set of stories within a sprint, have the work accepted by the business owner, technical reviewer(s) and have zero defects carried over in to the next sprint.

Velocity measures a team’s capacity to do this, by counting Story Points of the stories that are accepted during each sprint. Over time, as a team gets more productive, the team is able to design, code, test and accept more Story Points in a sprint and the Team Velocity rises.

Read More

Welcome to Agile by the Numbers

Posted: Monday, February 3, 2014

By: leor

This series of articles delves into the sticky topic of Agile metrics. Let me state right off the bat that this is NOT focused on measuring the performance of an Agile team for purposes of benchmarking or report-card scoring, although you will get some nice data for this purpose if you follow along.

The main purpose of Agile by the Numbers is to put a small number of key sensors in place, to create information for the Agile team to see where they are headed and where they can focus to improve their success.

I prefer the term “sensor” to “metric” because I believe that the purpose of any measurement is to improve a team’s ability to sense and respond to issues affecting their success. Metrics, on the other hand, tend to be more management-focused and frequently do not deliver this type of value at the team level.

Read More