We created Redocd to make working together as a team as easy as possible. We had every role in mind when creating the layout for the Propage, to make knowledge management as painless as possible. So just to provide a simplistic setup for most teams, here’s a scenario facing teams today within product development, broken out by role and deliverables:

  • A Product Owner builds the stories and prioritizes (e.g. Jira)
  • A Tech Lead (Architect) maps out a process Storyboard (e.g. Visio)
  • A Designer builds a Wireframe and/or Mockups (e.g. Zeplin)
  • A Developer builds the software (e.g. Github)
  • A Tester writes the tests cases (e.g. Zephyr, Jira)

…and the Scrum Master helps pull it all together, and typically builds out the structure of the sprints using simply a calendar, and maybe a Wiki-type tool to pull everyone else’s work together. Even before work can be broken down into it’s components and put into a Project Management software (e.g. Jira, Monday, Trello, etc.), it first has be finalized by the entire team…and published.

This is the most annoying part for team members, as they want to “remain in their domain.” Devs want to stay in Github, and Designers want to stay in la la land. But seriously, a good Scrum Master will work to help the team see the vision of truly working as a team, and why pulling it all together helps everyone. Once everyone on the team sees the full picture, they are now working from an Understanding, understanding the heart of the problem being solved, rather than simply developing whatever is on a list somewhere in Jira or Asana.

Once your team understands the heart of the problem, and has bought into the solution that everyone on the team has worked to put forth, everything comes into alignment. Everything flows. Micromanagement disappears, minor design changes don’t cause heartburn to the Developers, and Testers truly understand the use cases that need to be validated. The team starts to work in harmony.

And when the team works in harmony, they move like lightning. Everyone on the team is bought in. Everyone is pushing toward the goal. Everyone is hopeful that this feature, this thing being developed will make the end user’s life better, more enjoyable and more profitable. Everyone believes in what they are doing.

Without Understanding, team members are merely checking a punchlist of items. Team members are more focused on just getting to the finish line than working together, and building together.

Getting to the finish line on time is extremely important. When your team has Understanding, and truly buy-in into what they are doing, they will beat the timeline. Guaranteed. Double Guaranteed. If you build a team that not only builds, but believes, they will produce long after they have received their reward, and long after the go-live.

Dane