In my article, “10 Tips for Succeeding with Enterprise Agile Development”, I referred to the need for a common vocabulary and standard rules for agile software development teams. You’d think these would be obvious and simple. They’re not.
A common problem in large development organizations lies in simple communication issues. Every software group establishes its own vocabulary and rules. When teams try to work together and share information, struggles quickly surface and the relationships get off on the wrong foot.
A common vocabulary helps.
For example, if software teams are using multiple development cycles over the course of projects, are those short cycles called increments, iterations, sprints or something else? Is the person making product feature decisions, the product owner, product manager, marketing manager, business analyst… You get the idea.
It’s fine for a group, working independently, to define a vocabulary for itself, particularly for internal concepts that are unique to the group and its deliverables. It’s not so fine when the group has to exchange information with other enterprise groups. People outside of software development don’t have the time to learn unique terminology for each software group they assist.
Sure, vocabulary differences are quite common — but so are misunderstandings. It’s really not that hard to get everyone on the same page with regard to commonly used terms. Don’t try to institutionalize every word people use. Identify the keywords that span organizations and migrate them to a common vocabulary. It will save you lots of headaches.
Here are a few areas where a common vocabulary can help:
- Project Management and Governance
- Software Test Results
- User Interface Elements
Standard rules also help.
For example, every software project, regardless of development approach, should have a “definition of done”. If someone on the team is asked to complete a task, how will the team know that the task is really finished? Teams need rules to guide them through such topics.
Many teams still use “percent complete” to indicate task status despite a large body of evidence showing how unreliable that metric can be. Always remember the adage that 80% of the work takes only 20% of the allotted time.
Teams can establish whatever internal rules they want but when software must be turned over to another group, there have to be rules that govern the hand-off. If my expectation of “done” is quite different from yours, we are headed for serious miscommunication when I deliver software to you.
Here are a few areas where standard rules can help:
- Project Estimates
- Definition of Done
- Documentation Requirements
- Test Types and Test Coverage
- Source Code Layout and Naming (If the source will be handed off)
- User Experience Design
Enterprise agile development is not the same as small team agile development — it’s more complex and challenging.