This post is not a criticism of agencies but rather a list of suggestions from my experience working both for the clients in house, working for agencies as a consultant at the client side and also working fully agency side.
Most web agencies pitch to a budget as as answer to a brief out to tender. Agencies pitch/hazard a guess at an adequate number of days of UX, QA, developers, PM, BAs etc which they think would be adequate to satisfy a brief.
Sure, people want to know how much things will cost and the client has put it out to tender at a certain budget and time frame.
Of course, there are many flavours of Agile. I find Agile Kanban to make the most sense for most projects to date taking ideas from Extreme Programming (XP).
Energy of the team
Generally, agencies I have worked for with less rigid hours and better flexibility from home have much healthier developer teams. Programming is laborious and sometimes requests are really uninteresting like "make the button 48pt on Step 3 of the BLAH app", and regular breaks with time away from the office creating a culture of healthy productive developers.
Make the most of on-site developers time by scheduling the Agile sprint planning session, backlog refinement and agile retrospective.
Frequency of the agile meetings
People can go lax for agile meetings, some team members simply do not see the point if they are non technical. PMs, BAs can take the ownership of the product delivery and start to intrigue a genuine interest in how things are made.
How seriously the meetings are taken
It can seem a bit pointless to score points in a small team where you know who the back end person is, you know who is comfortable with the frontend and also you have possibly somebody who generally looks after one speciality.
How work is divided.
Further on the note above, it is good for teams to collaborate and share the pain points and knowledge from their discipline. I have no idea when this trend to have strict front/backenders happened, but we had webmasters who could put a whole page by themselves before all overcomplicated frontend tooling and extensive knowledge was needed for backend technologies.
Keeping the stand up interesting
Make stand ups fun and entertaining. It's the opportunity for the team to get excited and aligned by work. It's a great idea to start off with the backlog instead of the current work in the sprint. Here you can unlock some great quick wins.
Make sure you just use a SIMPLE video/mic solution for standups, like Google Hangouts or even better had great success with https://appear.in. Invest in a good mic for the team and also recommend team members use headphones.
Generally they are replying to a brief or rigid waterfall document and it will not need an Agile flavour like Scrum.
Involve all users in the technical architecture! Find hidden talents and experience that other members have. Do not have a top level down architecture where one person submits a proposal to stick with.
Let the client in on the agile meetings!
Agencies generally shield their designers/developers from client requests to reduce scope creep, reduce general queries and general PC Support Calls on how to clear your browser cache. These can distract developers but from experience with teams that involve the client, both the team and the client can collaborate and come up with creative solutions to tickets assigned to business goals.
However, even with a waterfall project, you do essentially have a GANTT chart of sprint goals, the bars on a GANTT chart are always super vague anyway!
Asking the client about the next sprint
This is not only an opportunity to sell more development time, but also really helps the team focus on any fixes that will be needed to support the next sprint.
ALWAYS do an agile retrospective.
I find this actually works only really with 3+ member teams otherwise they can become a bit samey samey. Invite people of all disclipines, involve your design/UX/UI to come along to voice their opinions on their product, comment on work and even congratulate/compliment good work!
It's a healthy feedback loop for developers who are always questioning their abilities.
Some of my favourite insight into developing software come from a number of books, I will try recall all the books I have read that have influenced my style of