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

Researching leadership for a book I recently interviewed a Scrum Master who had done their thesis on Integral Leadership. When I asked about their ideas on leadership their immediate reply was, “We don’t talk enough about followership.” They then proceeded to spend the next 40 minutes talking about leadership.

In their defense I didn’t ask about followership but the comment stuck with me because I realized that I too was guilty of staring awestruck and tunnel-blind at the position that seemed to hold all the impact, value, and power.

But how much of this puzzle of human organization actually is the result of leadership?

I began by coming up with a list of the traits that make for a good follower.

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

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.

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.

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. 

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.

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.

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?

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.

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.

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>

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.

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.

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.

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.

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.

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 as if people were gratuitously dropping the term so that their resume would be picked-up when a keyword search was done.

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.

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!

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.