Agile for non-tech teams: 8 things you need to know
Can your team benefit from using Agile if you are a non-tech startup? Yes! Read on for juicy details on how to make the fullest use of Agile in non-tech teams
A short disclaimer right away:
This guide focuses on briefing developers, not web designers.
Browsing through dozens of brief samples available online, we noticed a tendency: many of them include info valuable mostly for web designers, not web developers. If you don’t know the difference, check out our guide on hiring web developers. In it, we go in detail on the differences between web designers and devs.
Now, why is a brief document so important?
In brief (sic!), because without it, your devs won’t be able to do anything. Or they will, but it’ll be not what the client was asking for. You are the devs’ eyes and ears. You meet up with clients, you hear them out, you package their rambling into meaningful words and pass them on to the devs. Based on the documents you produce, they estimate project costs and deadlines, formalize client requirements into tasks and start working.
The quality of communication between you and the developers directly influences the project during its entire course! And the brief document is what this communication is going to be based on.
This is why you can’t just tell the devs, “You do this!” and slack off.
In this article, we’re going to analyze what a proper brief should look like, what info is junk to your dev team, and what you can do to facilitate their work.
Let’s roll.
Now let’s figure out what info your typical brief to your engineer team should contain. We discussed this matter with Daniel Brady, a Senior Software Engineer at Tapjot, Inc., and he actually opened our eyes to a bunch of things.
Even though developers work on technical things, some non-technical info about a project is still required.
Make sure to cover the following points:
“Will meeting these goals provide short-term value, or are they steps towards some longer-term success, or are they both? How will achieving these goals impact the business? And, perhaps more importantly, for each goal, what is the impact of missing it?”
It’s great when the client comes all-prepared, holding a written list of desired website functions in their palms. Like, “Hey, project manager, please tell your devs that I want the users of my website to be able to:
– subscribe to the website’s newsletter
– register an account
– quickly follow the website in social networks
– download a white paper, marketing materials, etc.
– put an item into the shopping cart
– comment on the blog article
– subscribe to the website’s RSS feed
– put stuff up for sale
– leave a message or ask a question on a forum
– contact the support team through the pop-up chat window.
Blah-blah, thank you.”
In this case, you’ll just have to pass down the requirements to your devs!
Unfortunately, clients mostly come with vague requests like, “You tell me what I want,” or “I want a beautiful fast website with many visitors.” In this case, you and your team will have to work out the project from scratch, thinking over the functionality based on the info you managed to squeeze out of the client. This is when the detailed info on the project goals and outcomes comes in handy.
The same applies to website navigation. If able, provide the developers with the info on what pages the website will have, and what its organizational structure is going to be.
Specify any additional features the client wants the website to have. This is often what clients, not developers think about in the first place. It can be anything, like:
– image galleries
– interactive maps
– website search
– homepage with looped background animation
– feedback form
– weather widgets
– star ratings
– comment section
The exact list of features will obviously depend on the desired project outcomes, objectives, functions, and navigation.
To illustrate, provide your dev team with references. Ask a client to point out the competitors whose websites possess the desired functionality.
In fact, references may comprise even the websites not related to the industry your client operates in.
Here’s what your hired developers probably won’t need to successfully do the job.
“Green fuel is our passion, and we dream the whole world will one day realize the benefits that dung fuel can bring to humanity. Therefore, we strive to…”
Nope. Developers don’t need to know what your client sees their calling in. They want to know what your client is trying to do with the help of a website.
This is the kind of info web designers will value. Developers turn web design into code and a working website, they don’t design the website itself.
Unlike references that may serve as starting points and do not oblige devs to anything, mockups imply specifics. Unless you and the client know from the very beginning, what the final product will look like (which is rarely the case), avoid using mockups on the briefing stage.
And again, for the engineering team, this is junk. Don’t bother developers with it. Instead, ask yourself a question,
“How can I actually help the engineering team instead of being a pain in the neck, jumping out of the blue with the new project requirements three times a day?” Wow, congratulations! A truly marvelous question! Here’s what Daniel advises:
In other words, let the developers do technical stuff, and focus on communication. Don’t try to control the engineering team. Instead, do your best to ease their job by providing all the necessary info upon request.
Daniel believes that as a project manager, you should discuss the brief with the engineering lead before providing the client with final estimates. For this to be possible, do send the document to the engineering team in advance! Discuss it with the developers, talk to the client, correct the brief, and hand its final version to the devs.
Another piece of advice suggests that you don’t call up project-related meetings all the time. This is only distracting the developers from work and expands the time they’ll need to successfully finish the job. Instead, to co-ordinate and monitor the work, Daniel recommends creating a Slack channel for all communication on the project between you and the developers. This way, you’ll have all the info in one place, which is great for retrospectives.
Also, abstain from using terminology. Showing off is never a thing, especially when working on important projects.
If we hear you use a technical term, we might think you understand more than you do about something, which can lead to big communication issues!
Briefing a web developer effectively requires defining the project’s scope, providing relevant materials, communicating your vision, discussing the budget and timeline, and establishing a communication plan. By following these steps, you can ensure that the web developer has a clear understanding of the project and can complete it successfully.
A web project description is a document that outlines the goals, requirements, and expectations for a web development project. Here are a few steps you can take to write a web project description:
Define the purpose and goals of the project: Clearly state the purpose and goals of the project, including the specific problems or challenges that the project is intended to solve.
Outline the target audience: Describe the target audience for the project, including any relevant demographic information.
List the key features and functionality: Outline the key features and functionality that the project should include, such as specific pages or functionality.
Specify any technical requirements: Identify any technical requirements for the project, such as the need for mobile optimization or integration with specific software.
Describe the desired design and branding: Provide any relevant information about the desired design and branding for the project, such as specific color schemes or fonts.
Set expectations for timeline and budget: Outline the timeline and budget for the project, including any milestones or deliverables.
A project brief is a document that outlines the goals, requirements, and expectations for a project. A good project brief should be clear, concise, and comprehensive and should provide all the necessary information to allow the team or individual working on the project to complete it successfully. Here are a few key elements that make up a good project brief:
Clear and specific goals: A good project brief should clearly define the specific goals of the project and what success looks like.
Target audience: The project brief should outline the target audience for the project, including any relevant demographic information.
Key features and functionality: The project brief should list the key features and functionality that the project should include.
Technical requirements: The project brief should identify any technical requirements for the project, such as the need for mobile optimization or integration with specific software.
Design and branding: The project brief should provide any relevant information about the desired design and branding for the project, such as specific color schemes or fonts.
Timeline and budget: The project brief should outline the timeline and budget for the project, including any milestones or deliverables.
Provide context: Begin the introduction by providing context for the project, including any relevant background information or context.
Define the problem: Clearly define the problem that the project is intended to solve. This should include a description of the current situation and how the project will address it.
Outline the goals and objectives: Outline the specific goals and objectives of the project, including what you hope to achieve and why.
Describe the target audience: Describe the target audience for the project, including any relevant demographic information.
Outline the key features and functionality: Describe the key features and functionality that the project should include.
Provide an overview of the project timeline: Provide an overview of the project timeline, including any major milestones or deliverables.
Can your team benefit from using Agile if you are a non-tech startup? Yes! Read on for juicy details on how to make the fullest use of Agile in non-tech teams
Everything you need to know about working with remote teams effectively, in details