Nonfunctional requirements describe aspects of the system that do not map onto a single piece of functionality. Essentially, they're constraints you need to operate within. Allan Kelly details how running performance tests regularly can be the key to nonfunctional requirements, as well as how much value these constraints produce.
As agile has grown in popularity, so have the misconceptions about it. In a recent introduction to agile webinar we asked our audience which of these common myths they’d encountered — here’s what they said:
Do any of these look familiar to you? Let’s dive into these a bit and separate truth from fiction.Agile = Scrum
Quick: what’s the first thing you think of when you hear the word agile? For many of us it’s a “standup” meeting. Or maybe it’s creating a “backlog” of user stories that get delivered in a two-week “sprint.” Fact is, these are all elements of Scrum, a popular project management methodology used by many agile teams. So Scrum is a framework for developing and managing work, while agile is an umbrella term for approaches like Scrum that share a common set of principles — but this isn’t about the semantics.
Scrum is just one of many methodologies that build on agile principles (others include Lean, Kanban, Test-driven Development, and Xtreme Programming). Simply “doing Scrum” doesn’t make you agile.
To “be agile” means focusing on customer value and quality, delivering value incrementally, limiting work in process (WiP), enabling cross-functional collaboration, and striving to continuously improve. When agile fails to take hold or improve results within organizations, as Rally VP of Product (and former coach) Ryan Polk has discussed, it’s often because it only lives in pockets at the team level or because it’s executed poorly. Sure, scaling agile more broadly means mastering the fundamentals of Scrum, but it also means adopting an agile mindset in how your teams, programs and departments work together and communicate with each other.
If you haven’t already read the Agile Manifesto and its 12 principles, and thought about what “being agile” (not just “doing agile”) would look like in your own organization, there’s no time like the present.Agile Means “We Don’t Have a Plan”
Equating agile with a lack of planning is one of the more insidious agile myths. We know its likely origins: the misguided observation that agile at the developer level seems allergic to functional specs, and the belief that adapting to change means abandoning whatever plan you did have.
Well, maybe you’ve seen the iconic “planning onion” before?
While it’s true that agile approaches trade the lengthy, upfront planning process for a more adaptive, iterative process, planning is a very important agile tenet. It’s just that instead of making one grand plan, once a year, and hoping that it’s still on target six months later, you’re dividing your planning (like the work) into smaller chunks and committing to reviewing your plans on a regular basis. Why is it better to plan, and then plan to re-plan?
- Short-range planning helps you control WiP, which means you can deliver more value, faster.
- Midrange planning helps you communicate, make visible, and prioritize the most important work, ensuring small iterations add up to high-value increments.
- Long-range planning lets you take the feedback from your incremental delivery and use it to steer the business in the right direction.
This might be one of the most fear-provoking misconceptions about agile — at least if you’re a project manager in a non-agile environment — and it reflects a fundamental misunderstanding about the roles on agile teams, which skills are most valued, and the fact that changing your collaboration dynamic can make people work more efficiently, happily, and productively.
The truth is that agile needs project managers — but it’s likely you won’t be called a project manager (you’ll probably have a title like Scrum Master or Product Owner), and it won’t be your job to tell people what to do or when to do it. That’s because agile approaches value self-managing teams — whose success relies on collaboration, localized decision making, regular communication, and tools for visualizing and sharing WiP.
For example: are you good at working with stakeholders, managing expectations, and balancing competing priorities? Do you have a strong sense for business value? Are you comfortable driving vision and strategic direction, while collaborating with a team to make day-to-day tactical decisions? Then you might be a good Product Owner. Do you understand people – their motivations, fears and desires — and group dynamics (what makes a team better than the sum of its members)? Do you enjoy problem solving for people so they can do their best work? Then you might be a good Scrum Master. (Learn more about how traditional project management maps to agile project management.)
Multiple analyst firms predict that agile approaches will dominate other methodologies in the coming years, and software-driven innovation means agile is gaining a foothold across nearly every industry. The Project Management Institute has found that the use of agile methodologies is up 27 percent from just two years ago, and a PricewaterhouseCoopers survey found that nearly two-thirds of these agile projects are managed by certified agile practitioners. And even though it’s a bit of a misnomer often used by companies transitioning to agile from waterfall practices, search for “agile project manager” on indeed.com and you’ll see that this is an in-demand role.Agile Doesn’t Believe in Documentation
It’s true that the Agile Manifesto values "working software over comprehensive documentation." However, this doesn’t mean documentation has no place in agile approaches. It’s just that instead of assuming a project and its associated processes require comprehensive documentation, you should undertake and design project artifacts because they provide value. Rather than drafting pages and pages of requirements and use cases and process rules, for example, think about the minimum viable information that needs to be captured, with whom it needs to be shared, how to document it in a collaborative way, and how that documentation might help you continuously improve.
Think about the roles on a delivery team — how people spend their time and how the tasks they perform correlate to a project’s success — and you’ll probably conclude that success maps directly to the time spent designing, building, testing, and shipping … not the time spent documenting all those processes.
Some roles will rely more heavily on documentation than others: for example, our UX designers do a lot of ethnographic research and customer interviews before they work with teams to design and build features, and their results need to be codified and shared. And when we do sprint or planning meeting retrospectives, we like to document what we liked, learned, lacked, and longed for, because capturing that information helps us improve over the next cycle. The point is that documentation isn’t the point in agile; it’s a byproduct of the actual work, and like the work, it should be designed to deliver value.Agile Only Works for Developers / Software
Agile may have started out in the technology realm, but like any set of effective practices, it has evolved and taken hold across a much broader audience. From finance and healthcare to communications and manufacturing, non-software companies — now finding themselves driven by software — are using agile approaches to improve their delivery, customer experience, and innovation. Organizations buoyed by the success of agile in their IT or engineering groups also have invested in extending agile principles and approaches into the executive suite.
Agile principles are now being applied to marketing, legal and human resources departments, and McKinsey recommends that companies should borrow agile approaches from their IT departments to build agility into their company DNA. No matter your organization type or your current way of working, wouldn’t you like to be faster and more transparent? Wouldn’t it be great to know that you’re delivering what customers really want? Don’t you want to know that you’re doing the highest-priority work and that you can reprioritize when your competitive, economic, or strategic landscape changes? Agile companies do this.Agile Will Fix All Our Problems
You know better than to fall for this one, don’t you? No one thing is going to fix ALL your problems. When leaders have problems that need fixing, however, they tend to search for a silver bullet. But pinning all your hopes on a “magical methodology” is going doom you to disappointment. Just as doing standups or buying an agile tool doesn’t make you agile, integrating agile practices into your IT group isn’t, by itself, going to turn your enterprise company into a nimble startup.
If you think of your company as having a fitness goal, then adopting agile approaches is like a workout. Exercising your agile muscles takes discipline and commitment, and if you do it on a regular basis, it can make you much stronger. But to meet your larger fitness goal you also need to change other habits: let’s say, eat well and get enough sleep. And your agile muscles become even more powerful and effective with supportive infrastructure — like the right training, a commitment to change, and engaged leadership.Bust Your Own Myths
If you’ve encountered any of these myths about agile, it might be time to brush up on what you think you know. We’ve put together some resources for you to do this easily on our Discover Agile Toolkit page. Learn how to make the business case for agile in your organization, hone your agile practices, get the scoop on role-based training, and take agile to the next level. Or check out the Discover Agile webinar recording to get an introduction to agile, Scrum, and the ROI you can expect at your organization.Jenny Slade
I would like to get the details of the course
-by Praseetha on 9/29/2015 at 1:58 PM
For a much more detailed explanation of different levels of learning, I highly recommend From Novice to Expert, by Patricia Benner. Though about nursing, I found a lot of it applied pretty much directly to my XP coaching.
-by Curt Sampson on 12/11/2008 at 8:11 PM
Someone vidd’d me describing Shu Ha Ri in my agile class, so I uploaded it: Vid of Alistair describing Shu Ha Ri (discussion: Re: Vid of Alistair describing Shu Ha Ri)
-by Alistair on 7/22/2010 at 4:25 PM
FYI Just posted a link between Shu-Ha-Ri and Daniel Kahneman’s awesome new book on the workings of the mind. http://www.agilekiwi.com/peopleskills/understanding-ourselves/becoming-an-expert/
-by John Rusk on 1/21/2012 at 2:11 AM
Is there a meaningful/useful/reasonable distinction between mastery and expertise?
I’m beginning to consider the conversion of ‘recommended’ software engineering from a culture of expertise to a culture of learning.
Probably a remnant of my earlier Deming reading, but it seems that development teams seek to learn, through practical exercise, bot what works for the customer/client/product owner/sponsor and what works for themselves/team/company.
This seems different from an artist learning to paint from a master (or a white belt from a black belt), where Shu-Ha-Ri results in mastery of techniques. This is the application of (learned, understood, or) mastered techniques to a dynamic/fluid environment — rather like surfing as opposed to skiing.
Hopefully, that’s close enough description to get the gist. Do you see such a distinction?
-by Skip Pletcher on 8/23/2012 at 10:37 AM
Hi, Skip: I do, personally. To me (at this instant) ‘expertise’ connotes mostly knowledge, ‘mastery’ connotes ability. As I see it, someone can be a master at something without knowing explicitly; whereas to say they have expertise, I would expect ability to articulate more of the nuances. Does that do you any good? Alistair
see also James Holmes’ page http://www.bifrost.com.au/post.cfm/the-meaning-of-shu-ha-ri
Evidently the akidofaq website is no longer funtioning. For those who are interested in a revised version of my ShuHaRi article, it’s a two parter on the kendo-world dot com website.
Sorry for the whacked out links but I don’t want this to be destroyed by the html link filter:
www.kendo-world dot com /wordpress/?p=1822
www.kendo-world dot com /wordpress/?p=1824
-by Ron Fox on 9/29/2015 at 8:58 AM
Visually deconstructing paint on ladies,
Pencils poised, pursed lips puckered
Feigned indifference, as though
they – I – know
what they are doing.
But they – I – are here anyway,
So they will just continue
To deconstruct in silence
© Alistair Cockburn, 2015.
Testers who analyze quality in every aspect of the team’s deliverables also have a responsibility to mitigate risks and practical issues that are bound to come up, and help the team succeed in their product as well as at being agile. Here are five such issues that testers can help the team alleviate or avoid.
When you see the world through the eyes of another person
you are seeing the other person.
When you see another person through your own eyes
you are seeing yourself.
The God that split into an infinity of pieces to experience life
sits behind you, before you, in you.
The God you see behind you is you.
The world you see before you is you.
As I feel, you are.
As I see the world, I am.
You lead yourself through the darkness;
you are your own light.
The light reflecting off others
is your own light reflecting back,
the light of millions of others
lighting their own way
through the darkness.
When you see the world through the eyes of another person
you are seeing the other person.
When you see the world through your eyes of yesterday
you are seeing yourself yesterday.
But yourself is always new,
different from ‘just now’.
The light reflecting off others is your light,
out of time with yourself, just now…
and the lights of others,
millions of others,
are the lights of stars
long moved on.
That light you see in others
is your light, reflected,
reflecting also the millions of others
lighting their own way
through the darkness;
the lights of others
the lights of stars
long moved on.
That light you see in yourself
is your light, reflected,
delayed, out of time with yourself,
long moved on.
© Alistair Cockburn, 2011.
(Thanks to Krishnamurti, “Meeting Life” p 57)
“As I look at myself I am learning about myself. Do I accumulate knowledge about myself, and then, with that knowledge, observe? Is this the same as looking at myself through Freud? Can I learn about myself without any accumulation? That is the only way to learn, because ‘myself’ is always moving…. I cannot learn about his through something static, whether it be the knowledge I have accumulated about myself or Freud. Therefore I have to be free of the knowledge I gathered about myself yesterday.”
Question: Which of these 7 things are eating your budget?
- Dependencies that block. Forces beyond your control are wagging your work.
- Risks that explode. External or internal, visible or not, you didn’t account for these.
- Unrealistic plans. Your roadmap may look good on paper, but it’ll never happen.
- Lack of commitment. Without a realistic plan, teams won’t believe they can get ‘er done.
- Unstaffed priorities. This is important work for which you don’t have capacity.
- Frequent pivots. You keep changing your mind, which changes the direction of the work.
- Late delivery. Be honest: given all of the above, what are the chances you’ll ship on-time?
Okay: have you determined your answer? Hold that in your head for a minute, because we’re going to come back to it.
Right now, let’s agree that we all want to do more with less — or at least get more out of what we have. And when businesses point the cost / efficiency finger, the development organization is often the fall guy: it’s not moving fast enough, or producing sufficient results for the money spent.
Here’s the spin on that finger-pointing: the secret to delivering more value doesn’t just depend on the speed or efficiency with which we build and deliver things. We also need to be building and delivering the RIGHT things.Like a Bucket, Your Capacity Is Fixed
It's time to stop looking at your people and individually putting them on projects. Instead, think of the development organization as a bucket, with the team as your resource unit. Like any bucket, it has a fixed capacity: You’re trying to fill that thing with as much value as possible, but anything you put in beyond the rim is going to spill over. Now think of waste in the development organization as holes in the bucket: we’re always losing a certain amount of capacity due to inefficiency, pivots, delays, etc. What’s left in the bucket is our run rate.
When organizations want to improve, most of us start by plugging the holes in the bucket. And we tend to start by trying to solve the most visible problems, sometimes we need a means to make the problems more visible. By filling the holes we set ourselves up for growth in a deliberate, efficient way. We’re optimizing the capacity we have before we make it bigger.
Let’s say we DON’T plug the holes in the bucket — and we try to increase our capacity to deliver value without fixing them. Guess what? When that bucket gets bigger, our waste gets bigger, too, because it’s relative to our bucket size. In fact we may actually be losing more money if we spend on growth without filling the holes, because that proportion of waste-to-value hasn’t changed. On top of this, we risk overloading the bucket or putting so much pressure on the holes that they get even bigger than they were before.Fix the Holes, Then Fill It with the Right Stuff
So let’s start by fixing the holes in the bucket, because plugging these holes means we’re optimizing the run rate of our organization. But recognizing that our capacity is still fixed, and that we have limited funds for a bigger bucket, how do we get more value from what we’ve got? The secret is to put the RIGHT things in that bucket. What’s the point of plugging the holes, after all, if your bucket is filled with the wrong stuff?
Here at Rally, when we do quarterly company steering, we’ve used a concept borrowed from Verne Harnish's book, Mastering the Rockefeller Habits. A “rock” is a company-wide initiative or chunk of work that has the highest value for the organization. These rocks are the first things we should use to fill our buckets. If there’s more space after we’ve added the rocks, we can put in some pebbles, or medium-sized projects. With any remaining space we can add sand, or the tactical tasks. And finally, we can add water, or the ad-hoc things that come up.
What we find is that if we fail to put the big rocks in first, our buckets will be filled with just pebbles, sand, and water: the things with the least value to the company.Do Both at the Same Time
At this point you’re probably thinking, Is it too much to ask to want to fill our bucket with the right work AND plug the holes? No, it’s not. There’s a method for eliminating the waste that’s eating your budget, AND doing the business alignment and ruthless prioritization that ensures you’re building the right things. It’s called big room planning.
Big room planning is a realtime, collaborative activity that brings together everyone associated with getting a deliverable out the door: engineers, testers, product owners, directors, even executives. In big room planning, you connect your development work to your company’s highest priorities; plan and scope your work to your actual capacity; flush out risks and dependencies; and commit to a realistic plan for the work ahead.
Remember the question we asked earlier, about the seven things eating your budget? When we walk about those seven things with customers, everyone nods and frowns. These are the issues creating those holes in the bucket — and causing it to fill it up too quickly with sand and pebbles. Here’s how big room planning changes everything.
BEFORE BIG ROOM PLANNING, YOU HAD:
WITH BIG ROOM PLANNING, YOU'LL:
1. Dependencies that block
Visualize your dependencies
2. Risks that explode
Identify and ROAM risks
3. Unrealistic plans
Create team level capacity-based plans
4. Lack of commitment
Make a shared commitment with everyone
5. Unstaffed priorities
Set business context and collaborate with stakeholders
6. Frequent pivots
Visualize work, aligned to business strategy
7. Late delivery
Deliver often while planning on a cadenceLearn More About Big Room Planning
A wise man once said,“If you can heal the symptoms but not affect the cause you can’t heal the symptoms”
Big room planning is an investment: one that pays exponential dividends. Instead of solving just the visible problems, one at a time, it helps surface all of the problems in a forum that allows a delivery organization to focus on fixing the things that will return the greatest value. Done right, you’ll have the important people in the room who can take action and make change happen right there.
Join me for our Big Room Planning webinar on Tuesday, October 6, to learn more about how this key ceremony can help you get more value out the door.
DATE: Tuesday, October 6
US TIME: 11:00 AM - 12:00 PM MST
EMEA/UK TIME: 15:00 BST (8:00 - 9:00 AM MST)
Big room planning has become such a fundamental part of successfully scaling agile that if you’re not doing it, you’re not getting the most out of agile. Don’t be content just to plug the holes in your bucket: challenge yourself to build and deliver more value with the capacity you have. Get in a room together and solve your most important problems.Andy Carlson