You are hereFeed aggregator

Feed aggregator

Assessing Team Improvement

All About Agile - Mon, 10/05/2015 - 11:44

I understand that managers who have invested effort and money in training teams in Agile methods may want to see how much those teams are improving.  There are a handful of reasonable measures to look at to see whether the organization is improving over all (which I’ve written about here and here). You can apply some … Continue reading Assessing Team Improvement →

Busting 6 Common Myths About Agile

All About Agile - Tue, 09/29/2015 - 14:56

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.
Agile Doesn’t Need Project Managers

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 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

Dependencies Are Evil

All About Agile - Tue, 09/22/2015 - 05:00

It seems inarguable to me that dependencies limit agility. If I am able to make a decision on my own that only involves me, I have full freedom of movement. If I want to go to the local pub for dinner, and on my way, decide that I want to go to a steakhouse, I […]

The post Dependencies Are Evil appeared first on LeadingAgile.

The First Critical Steps Toward Scaling Your Software Organization

All About Agile - Mon, 09/21/2015 - 05:00

I’ve noticed a pattern I want to share with you guys. When a company is small, still probably led by it’s founder, likely around 20-40 people… there is a great sense of camaraderie. You’ve got folks that all know each other, all working toward a common goal, all trying to solve the same problems. To a large […]

The post The First Critical Steps Toward Scaling Your Software Organization appeared first on LeadingAgile.

Agile Awards

All About Agile - Wed, 09/09/2015 - 05:37

hi all, I’m nominated for the Agile Awards ‘most popular online contributor’ this year for this blog. If you have found it useful, your vote would be much appreciated: Many thanks! Kelly.

Scrum Alone Is Not Enough – InfoQ and Agile 2015 Interviews

All About Agile - Thu, 08/13/2015 - 14:32

Mark attended Agile2015 in Washington and, as part of his conference commitments, he sat down with ​SolutionsIQ for an Agile Amped podcast about High-Performance Teams, as well as with InfoQ for an on-camera interview to discuss his Scrum Alone Is Not Enough blog series. InfoQ recently interviewed Mark regarding the motivation behind the blog series and how his experience as an Agile expert has formed his viewpoints. You can read the full interview at And you can view the video from the Agile Amped podcast here. We will post links to the InfoQ video interview as it becomes available.

Teams and their proximity to the final user

All About Agile - Wed, 08/12/2015 - 21:12

Learn more about our Scrum and Agile training sessions on WorldMindware.comA great, simple post from Mike Bowler… Time: Teams that are writing code today that will be used by their customers tomorrow are very focused on what the customers actually need. Teams that are writing code today that won’t be seen by a customer for … Continue reading Teams and their proximity to the final user →

The post Teams and their proximity to the final user appeared first on Agile Advice.

Three Things You Need to Know to Transform Any Sized Organization Into an Agile Enterprise #agile2015

All About Agile - Tue, 08/04/2015 - 13:46

Here is my talk from this AM at the #Agile2015 conference. Enjoy! The Three Things You Need to Know to Transform Any Size Organization Into an Agile Enterprise from Mike Cottmeyer The post Three Things You Need to Know to Transform Any Sized Organi...

‘Agile Executive’ – workshop with Kelly Waters on 28 Sep 2015

All About Agile - Wed, 07/29/2015 - 21:27

Hi everyone, I recently ran my first ever public workshop – a 1 day workshop called ‘Agile Executive’ which focuses on topics to help managers and executives that are embarking on or part of an agile transformation. I am running another session on 28th September – details below… ‘Agile Executive’ Creating an organisation that is […]

Transparency – Two Way Visibility

All About Agile - Mon, 07/27/2015 - 14:44

What does the value of Transparency really mean?Nextgov: How do you define transparency?Fung: My definition is quite a bit different from the conventional wisdom about transparency. A transparency system is designed to allow people to improve the quali...

Is It Ready?

All About Agile - Mon, 07/27/2015 - 10:16

In an agile transformation, one of the first things we work towards is to create an ability to deliver in a predictable manner. As described in our compass and our journey, there is a clear path for organizations that embark on an agile transformation. By becoming predictable, an organization can make and keep promises. In […]

The post Is It Ready? appeared first on LeadingAgile.

Microservice Trade Offs

All About Agile - Wed, 07/01/2015 - 08:36

Many development teams have found the microservices architectural style to be a superior approach to a monolithic architecture. But other teams have found them to be a productivity-sapping burden. Like any architectural style, ...

Story Splitting: Where Do I Start?

All About Agile - Tue, 06/30/2015 - 07:16

I don’t always follow the same story splitting approach when I need to split a story. It has become intuitive for me so I might not be able to write about everything I do or what goes through my mind or how I know. But I can put here what comes to mind at the […]

The post Story Splitting: Where Do I Start? appeared first on LeadingAgile.

‘Agile Executive’ – 1 day workshop with Kelly Waters

All About Agile - Tue, 06/23/2015 - 13:11

Hi everyone, Until now, I have only offered training & workshops as part of my consulting service to clients.  Now, for the first time, I am offering an open workshop for managers and executives that are embarking on or part of an agile transformation.  Details below… ‘Agile Executive’ Creating an organisation that is fast moving, […]

Fear is Waterfall

All About Agile - Tue, 06/23/2015 - 03:05

This article was written by Haran Rasalingam and was first published on thetrainline engineering blog The big selling point of Agile is the fast return on investment it promises. But what excites me most about Agile is its emphasis on people – agility done well injects humanity back into activities which Waterfall has made bureaucratic and devoid of […]