Expert Q & A on agile projects
Being agile in your digital projects is about flexibility, learning along the way and perhaps most importantly trust between the agency and the customer. Over the past years, many members in the J. Boye groups have dipped their toes in agile waters as they’ve departed from the usual waterfall approach to projects starting with a long and thorough specification initially.
Still, we’ve heard about some of the pain points with agile projects, most notable around project team changes, budget overruns and difficulties getting a guarantee in place.
How agile are you really?
To provide some medicine for the usual pain points and to also highlight what it takes from the customer side to do agile, we’ve invited Karoliina Luoto from Codento to share her experience with agile readiness.
In the brief video below she shares some advice on purchasing agile web development projects based on 3 common project management challenges. To provide you with a balanced expert view for your own projects, you can read the response from another experience agile practitioner below and leave a comment to participate in the conversation.
The agency take on purchasing agile projects
I received the below from James Cannings, CTO at MMT Digital, a UK-based agency. Here’s his take on each issue:
#1 Getting the best talent: Team Good point about pitching with one team and then using another. Clients should watch that with suppliers. I would say that agile makes
this much, much easier for clients and much harder for agencies to get away with. With the complete lack of transparency that is required in waterfall (when I think back to the “dark old days”!) you can switch developers around whenever you like to suit your resourcing requirements. The client never knows. Agile really helps to enforce standing teams.
It can be a little harder for the agency to manage but much better for the client and much better for the developers (who hate being bounced around onto different projects….in the long term that is good for the agency in terms of staff retention). Definitely a big plus for agile this one really!
#2 Budget management: Not too sure about financial incentives done in this way. We, of course, have various financial incentives for the company but we have not introduced financial incentives at a project level. Boosting velocity and quality is always vital on agile (all clients want to stretch the budget as far as they can) and that is really about creating a strong agile culture, focused heavily about high quality (we have a “zero-defect team” that focusses on helping teams remove all bugs from their backlogs). We also make sure teams regularly meet face-to-face. We go for meals, drinks, days out, we’ve even taken a team to work in a house in France for a week as a team building exercise. We have social communities for the teams, team mascots, team mugs and we never use conference phones (video conference only for any agile meetings that you can’t do face-to-face!). We have the agile manifesto up as posters on the wall along with the team principles, we have team definitions of done printed out and we make sure that people enjoy the experience and that the team is having FUN. It is this environment that means that when the team commits to a sprint they are truly committing to their peers. They are NOT committing to a manager and it is not about money. In fact there is evidence to show that if you place too much weight on financial incentives that people will actually get less done! This is a great video on the Limits of Management by Carrot & Stick
I suspect that financial incentives could work BUT you have to get all that other stuff in place first. It’s much more important.
#3 Guarantee: I could talk about bugs for a long time. Bottom line is that bugs are the ultimate killer of trust with an agile projects particularly with a supplier / agency relationship. Nothing breaks down the process faster than the dreaded “bug sprint” (often hidden under the name “stabilisation sprint” or “hardening sprints”). These are bad. We never assign story points to bugs. If that causes problems with the team understanding how much they can commit to then they need to get rid of the bugs. No bugs, no problem! It’s all about TDD (unit tests on front end and back end code, selenium tests and getting it all automated through a good Continuous Integration / Continuous Deployment process) along with good manual testing during the sprint, strong acceptance criteria (we always use the Given / When / Then format) and having retrospectives to talk about quality issues as they appear. It’s tough but it is possible.
Clients are usually very understanding of a slightly slower velocity with high quality. Short term boosts in velocity to push through features are a false economy when you have a “stabilisation sprint” later on. That’s when the awkward financial questions start being raised!
Learn more about how to make agile work
While not as sexy as going mobile or social media, project management is an important topic that deserves more attention if we want to projects to succeed.
You can also read more about this topic in my posting on Agile is not the answer
Feel free to continue the conversation and share your experiences by leaving a comment below.