Our clients see right through us - and we wouldn't have it any other way. We pull back the curtains to give our customers an unobstructed view of our daily operations.
What Does Transparency Mean to Us?
As one of our core values, transparency means that we expose our processes, tools, communications, successes and failures with each client. That's right. We are an open book to each of our clients. We are a company built on top of an Agile mindset, meaning that we believe that by hiding nothing and exposing everything within each project to (and only to) its respective client, we can more readily deliver exceptional software and design to them.
There are many benefits of working with this level of openness. We immediately start to build trust with our clients by letting them see not only the product we are building, but the entire infrastructure supporting it. We enable our clients to tune project elements to best suit their business needs, including:
setting the length of iterations
frequency of grooming sessions
report generation and more
However, offering this level of visibility doesn't come without its challenges. For example, many clients aren't used to this level and volume of information and detail. For clients who regularly use a more traditional waterfall project approach, they generally define everything at the beginning, set up change request processes, and don't really engage until specific milestones. Our Agile approach requires this process to be much tighter across more frequent iterations, or sprints, necessitating closer engagement. We have a formal onboarding process at the start of the project that helps the client acclimate to our process, and usually after the first few iterations, they get it and begin embracing the process.
We don't expect our clients to watch over our shoulder for every design we craft or line of code we write, so our transparency begins with logging.
For client requirements, we log the work we do by breaking it into an atomic task, or story, which carries meaning and content in the Agile sense:
an actor - the person or group that uses a feature (e.g., user, admin, customer, etc.)
an action - the task that the actor will perform (e.g., sign-in, edit profile, share on social media, etc.)
a value - the benefit that the actor receives by performing the action (e.g., so that I can access my account balance, so that I can share my blog, etc.)
We keep these stories very specific and detailed enough so that our project teams can design, code, test and deliver a working piece of functional value to the client. Each story carries the full context of who, what and why so that the value is clearly defined and we all agree on what is being delivered. Then we continue to iterate through each new feature while improving existing ones as necessary, until we get to the desired outcome.
And while we're working on each story, we log our time against it internally so that we can measure and report on what was done, who worked on it, how much time was spent, and every detail, discussion, and comment related to that story. This creates an audit trail of the entire project, with context to help quickly identify and dive deeply into a concern, question or idea. Everything is captured.
But how does the client access all this detail? We have created "The Client Portal" which enables our customers to see all activity listed above, day by day, month by month, and throughout the entire project - any time, from anywhere, on-demand. From the portal, the client can drill down into individual logs, minutes from each meeting, individual stories, threads, documents and duration. The portal securely silos all the project reports, details and activities to each client, and keeps all IP secure and confidential. Nothing form one client's project is shared or visible to another client. Everything related to the project - Design, Code, Tasks, and Reports are stored securely in the industry-leading cloud service providers we use - nothing is stored on-premise other than the current work on which any given team member is working.
Invoicing and Billing
Further to our transparency, every invoice line item is generated directly from the logged activity listed earlier. There is no padding, estimating or generalization of work done. Invoices are backed with the entire detailed list of activities, broken down into project components:
Mobile development (iOS/Android)
Web development (Front-end/Back-end)
One of our greatest achievements is the level of communication we maintain through each project. The most important element to maintain transparency is that all communications are deliberately directed to the full team. We don't allow private "side conversations" or "siloed chats" and will immediately guide them back to the appropriate "public" forums. This reduces interruptions, personal agendas, scope creep, and team discord and keeps the conversation where it belongs - in front of the extended project team for all to see. Everyone is enabled to know what's been accomplished, what's being worked on presently, and anything blocking progress.
During our Client/Project onboarding process, we clearly define the applications and processes we will use, for example:
Slack - for daily full-team communications
Jira - for commenting on and tracking of all story-based work tasks
Confluence - for dialog related to the creation of all client requirements
Google Meet - for all project-related sessions where face-to-face isn't required
GitHub - for all source code management
Of course, we've accommodated other tools if/as needed based on client requirements or constraints (Zoom, MS Teams, Trello, BitBucket, etc.)
Information Radiators and Sharing
While a good Project Manager would always be ready to provide status and progress updates, we feel the need to take this much further. Clients should have access to this type of information on-demand without having to be gated by a single person. From the onset of each project, our clients are invited into the the apps that provide them details on what stories or tasks are being worked, who is working on them, what's coming up next, and any blockers, obstacles or risks.
We share minutes of every internal and client meeting we hold. We invite our clients to participate in daily standups and team retrospectives, and expose all captured data to our clients. We have sprint velocity, burn-up/down reports, and many custom dashboards as required by the business so that they can see the actual project status at any time.
Uncovering Our Tracks
There is no shame in failing. But as an Agile agency, we prefer to do it quickly and early. By exposing failure, we show our true desire to be transparent. We all make mistakes, and in software development, they are unavoidable. Sometimes they're legitimate defects, but often times they're missed requirements, use cases, or test scenarios. When a client is paying an agency to do work, there is an expectation that they're paying for perfect product. Perfect is a journey together, not simply meeting of a set of requirements. By sharing the outcomes - both positive and negative - we also begin to share the responsibility of working together to deliver the best-possible product. We are committed to learning from our mistakes, and taking steps to reduce the chance that they'll happen again.
We also have processes and tools in place to help us discover issues. We still report issues to the client through the established process - we don't attach any negative connotations to bugs and try to hide them. They are treated with the same visibility and attention as those reported by our clients. Since the prioritization of tasks is always the function of the client, they need to know about issues that we've found so they can react accordingly.
Being transparent may feel like a risk, but it's one that agencies should take. By embracing transparency at all levels, your will build trust with your clients and your teams can work in a "guilt-free" environment.
If we're the kind of agency you'd like to work with, contact us and experience the kind of transparency you deserve!
Another part which I liked was about openness using commonly agreed toolbox which slack etc. but as I searched more on this even highly skilled and matured scrum teams can miss transparency around it and start creating sub slack channels during meeting making secret silo of information which no one no about until asked. I like this video which touches about common scenarios that happen while implementing scrum, it’s named “transparency from the trenches” from scrum.org on YouTube.