Once I was watching a video from BA Conference Europe 2013 presented by Christian Heldstab. His talk was dedicated to «10 Things about Agile».
It was a really nice presentation highlighting the advantages & critical points in understanding the philosophy of Agile. However, as an Agile-minded BA I couldn’t but draw my attention to the point that actually encouraged me to write this article.
«Information is NOT knowledge». As a BA I treat it as a core because piles of documented requirements don’t produce any knowledge for the tem, they simply don’t work.
You can spend hours negotiating with customers, you can spend weeks working on the most detailed requirements document, but the knowledge of the project you’ve gained over this time will never be reflected in tons of words or diagrams.
While working with developers on different projects I’ve learned 2 things developers really hate:
- developers hate endless documents. They simply don’t read them. Of course, they like good specifications, but hundreds of pages don’t make a good specification – indeed, they make it totally useless.
A developer is most likely to come ask for clarification or to simply do whatever he/she deems necessary for the case rather than spend hours trying to follow your idea within dozens of pages.
- developers hate Project managers. The reason is simple: PMs talk a lot. Communication, negotiations, meetings of all sorts make an inseparable part of a PM daily routine. While for most developers talks are useless. Technically-minded people are practice-oriented. They strive to start coding rather that discuss methodologies, approaches, trends.
There’s no an internal war between a PM the dev team, but the more you speak – the less useful team member you become in your dev team eyes.
Agile processes help manage this 2 cases seamlessly efficiently.
- In agile you don’t need tons of documents. You focus on stories with a short description of who the user is, what the user wants to do what he/she will get as a benefit of these actions.
Besides, you provide the team with a definition of done (DoD). You your team are on the same page in understanding what the user story is about.
It’s short, it’s clear, it’s pretty straight forward.
- In Agile you manage your time. You do have quite a lot of meetings, but most of them are extremely short.
Daily stand up – in my team we discuss everything within 10 minutes.
Backlog grooming – 30 minutes (1-2 times per sprint).
Sprint planning meeting – 30 minutes (rarely – 1 hour as a maximum if required)
Retrospective – 30 minutes (once per sprint).
Documents become outdated pretty soon. If you have 60 pages of requirements written 4-5 months ago, you don’t have time to update them all on a daily basis. The project needs objectives of the stakeholders change quicker you are to progress with adjustments, with negotiations, with team communication rather than updating documents that don’t convey the knowledge.
You can read the Medical encyclopedia but it will not make you a doctor. The same thing works for requirements. Whether you are a BA or PM working closely with stakeholders – you do know all the details of the project.
However, even being an excellent requirements gatherer technical writer – you won’t manage to transfer your knowledge to the team via piles of requirements docs.
It’s communication with the team on a regular basis, keeping the team updated about the most recent changes project development plans that makes it possible for BA or PM to transfer knowledge to the entire team.
For me personally, the idea of a close team communication that is outlined in Agile methodology is one of the core factors that extremely facilitates the entire dev process. Moreover, it helps me transfer my comprehensive knowledge of the project that I gain when communicating with customers, project owners all parties concerned to my project team in a more efficient way than writing piles of documents that they never read.
I’m not a fan of doing useless job. Are you?
Powered by Facebook Comments