Agile Myths
As a Stakeholder or Product Owner
I want to understand what the common Agile Myths are
So that I know how to identify them when they are referenced
- Agile is a silver bullet.
- Agile is anti-documentation.
- Agile is anti-planning.
- Agile is undisciplined.
- Agile requires a lot of rework.
- Agile is anti-architecture.
- Agile doesn’t scale.
Agile is a silver bullet
I wish this were true – but it isn’t. You can fail just as spectacularly on an Agile project as you can using any other traditional method. You’ll fail faster using Agile (due to the transparency and visibility it brings) but unfortunately it’s not a silver bullet or an excuse to stop thinking.
There’s nothing inherently magical about Agile. It basically says
Bring your development team and customer as close together as you can, give them what they need, and then get out of the way.
Now if you don’t have people that like being empowered, taking initiative, and getting things done, that’s a different problem. Agile just gives them permission to do their best work and be accountable for the results.
Agile is anti-documentation
Agile isn’t anti-documentation. A more accurate way to say it would be Agile doesn’t do documentation for documentation’s sake.
Documentation gets treated like any other deliverable on an Agile project. It gets estimated, sized, and prioritized like any other user story.
Where Agile pushes back on documentation is as a means of communication. Agile prefers face-to-face communication over relying on the written word.
Agile is anti-planning
Not sure where this one comes from. There’s actually a lot of planning that goes on in Agile projects.
You’ve got your:
- Daily planning with the 10 minute daily standups.
- Bi-weekly planning with the Iteration/Sprint Planning Meetings
- Release planning where team’s decide what to ship every three to four months.
But it wouldn’t be fair to say Agile is anti-planning. If anything it is anti-static planning. Meaning Agilist’s expect their plans to change and use tools like burndown charts to track and make these changes visible.
Agile is undisciplined
When Agile started gaining popularity, its reputation suffered a bit from some teams taking the easy parts of Agile (like attending daily standups) but leaving out the hard (like upfront testing and regularly shipping production ready working software).
The truth is Agile is a very disciplined way of delivering software.
- You have to test.
- You have to get feedback.
- You have to regularly ship software.
- You have to change and update the plan.
- You have to deliver bad news early.
This isn’t easy stuff. It’s not for the faint of heart and requires a lot of hard work, courage, and discipline.
Agile requires a lot of rework
Rework comes in two forms on an Agile project. You’ve got the rework of requirements – customers discovering what they really want. And you’ve got the rework of the software – development teams discover better ways to design the software.
Both need to be balanced and tempered. Just as business can’t indefinitely keep changing their mind, development teams can’t forever keep redesigning the software. At some point we have to ship.
Agile deals with this tension by empowering both sides with the power to iterate, so long as they work within the project’s means.
Burndown charts play in big role in tracking how Agile project are doing. Just as tools like the Agile Inception Deck make sure everyone is on the same page with regards to time and money.
It’s a balancing act not unique to software delivery. Any creative work with a deadline (i.e. plays, movies making, or the publishing of daily papers) faces the same challenges.
The trick is to do the best work you can, with the time and resources you’ve got.
Agile is anti-architecture
Something we got really good at as an industry in the 1990’s was building big, complex, expensive, hard to maintain systems.
Agile pushed back on this over engineering by creating terms like YAGNI (You Aint Gonna Need It) to remind teams to keep things simple until proven otherwise.
That doesn’t mean Agile teams stop thinking, or don’t leverage previous experiences.
It’s more an attitude that the best way to build systems is to keep things simple, and only add the complexity when you need it.
Agile doesn’t scale
Agile scales like any other software delivery process. Not that well.
Look – scaling is hard. There is no easy way to magically coordinate, communicate, and keep large groups of people all moving in the same direction towards the same cause. It’s hard work.
The one thing Agile does bring to the conversation, is instead of looking for ways to scale up your project, look for ways to scale things down.
In other words, if we know we are really good at delivering with small, nimble, agile teams of ten, why don’t we structure our work that way. More on this here.
AgileBI Overview Articles
ODE & 3CPO – Talking multiple languages
When we decided to start building ODE we knew a few things already. One of those things was that most of our customers already had data warehousing technology.
They had already invested in Microsoft, Oracle, IBM, SAS, Teradata, Informatica or any of the other raft of data warehouse repositories and ELT technologies that are abound in the market place.
We also knew that it would be a big decision on their part to throw out this technology and implement the technology we decided to pick to be able to use ODE and gain the AgileBI benefits that it provides.
ODE – The start of a journey
About two years ago we started a journey into the world of AgileBI. It all started out of frustration (as most journeys do), frustration about the magic sauce.
The magic sauce was the reason why one data warehouse project would be a raving success and the next a ‘meh’. It was often the reason that after delivering a raving success and then returning 12 months later I would find the data warehouse had become a ‘meh’. By that I mean not updated, not well managed and not delivering to the stakeholders expectations.
The little things I love about YellowfinBI #5
User Guide Videos! Typically I dislike youtube videos and prefer to follow the tutorials to get something done. But when I was using the Yellowfin Append Sub Query functionality in anger the other day I just couldn't get it to do what I wanted, even as I followed the...
The little things I love about YellowfinBI #4
Subqueries! Often you want to manipulate the data you are using to get a report just the way the user wants. And often this requires you to do sub queries on the data you are using (for me it was creating columns for my measures based on offset periods, so I could...
The little things I love about YellowfinBI #3
Up to date and easy to find documentation! One of the coolest things about Yellowfin is that they do releases every month which includes squashed bugs and a raft of smaller new features, as well as point releases every six months or so, that typically introduce major...
Introduction
As a Reader of this site
I want to understand what it is about
So that I know whether I should keep reading
The little things I love about YellowfinBI #2
Making the impact of editing the semantic layers visible. When you edit a semantic layer that is being used by users, there is a high chance that you are going to effect the Dashboards and Reports they are using. Why? Because you are changing the underlying layer that...
The little things I love about YellowfinBI #1
Additive and Semi Additive Measures! When creating measures in your semantic layer (called Views in Yellowfin, Universes in BO, Information Maps in SAS, RPD in OBIEE etc) its important to be able to define your measures as additive or semi additive to ensure they...
Yellowfin makes changing view names seamless
One of the frustrations I have with many BI products I have used is that they often state all their components are fully integrated. But when you go to use it in anger you find gaps that increase the effort required to do simple things. Often its around metadata...