Projects can go sour for a variety of reasons, but we feel that communication is time and time again the main culprit. Here’s our simple, but strict method of communication with clients and internally.
Every Tuesday and Thursday (every day for huge projects) we have a 5-15 minute “Standup” with the client, where each developer or designer discuss these three things:
- What we worked on yesterday: The developer will discuss the feature(s) that they completed the previous day.
- What we will be working on today: The developer will discuss what they plan on completing that day.
- If there are any “blockers”: Blockers are things that will block the development team from progressing and finishing their user stories. A good example might be “We need the authentication credentials for that 3rd Party analytics service” It’s then up to the project manager to ‘unblock’ the developer by getting those credentials, or just asking the client to create an account and send over.
Sprint Planning Call
We have a 15-30 minute sprint planning call (we shoot for 15 minutes) every Monday where we have a ‘high-level’ of the previous week, talk about we are planning on accomplishing that week and to figure out any blockers for the development team. It’s ultimately a more powerful standup if the project management was setup correctly from the start.
Sprint Review Meeting
We only save these for our ‘Huge’ projects, and really don’t like to have them too often. We consulted with a startup that did these once a month, and calculated that the startup lost about $5k every meeting…This was a unique circumstance because the firm was paid hourly (so the more people on the call the better) but we found it just terribly inefficient and unethical for various reasons.
So, when we do have these meetings we only ask for ‘representatives’ from different departments to show up, and then send meeting notes to the entire team afterwards. We timebox it from 60-90 minutes, and make sure there’s a strict script to follow and anything that needs to be demoed is properly functioning.
The Goal of the meeting really depends on the project / startup, but it’s typically to ‘demo’ the product for the most important shareholders. We prefer to work directly with those shareholders from start to finish, even if it’s from a ‘chairman of the board’ oversight position, simply because we want to ship the product on time and on budget.
Deadlines can be very hard and very easy to set for software projects. They are easy when:
- We have fast design iterations and feedback cycles
- The client agrees to a ‘1.0’ after the design is finalized and we have minimal product changes
- The client looks to the ‘burndown chart’ as their guide to when we’ll be finished
- We do our job and have a consistent velocity each and every week.
- We have enough time at the start of the project to hit the deadline that’s forecasted by #4.
They are hard when:
- The client goes on vacation during the design cycle (yes this has happened multiple times)
- The client has slow feedback and communication during the design cycle, especially when we’re looking for a simple ‘yes or no’, OR ‘yes, but change this’ type feedback.
- The client wants changes to the product after we’ve already spent time on something else that was out of scope.
- The client adds more features onto the 1.0, or claims that a ‘nice to have’ feature has become a ‘must-have’ and is moved into our 1.0.
- We don’t have a consistent velocity, and fail to do our job.
- We make promises on a “launch date” that is based on ‘gut’ and not numbers. This is exacerbated when we haven’t worked with that client before, or we’re building a 1.0.
We have no problem giving ‘rough’ deadlines at the start of the project, but the client needs to understand the above. It just really sucks for all parties involved if we ‘miss’ an important deadline because the first few weeks were super slow or delayed for on feedback on a 5 month project, and we then miss the deadline by a a few weeks.
Trust us, we 100% understand the importance of planning and launch, but deadlines are just something if understood how and why they’ll change, then we can all build an amazing product together.
Retrospective / Retro:
Every two weeks we have an internal “Retro” where we have a fully transparent meeting to discuss the following:
- Things that we liked, or what went well
- Pain Points / What did not go well?
- What are some identified problems?
- What are some possible solutions, and what can be improved?
Take a look at one of our retros from early-on:
We will have these with our client about once a month. It’s a great open environment where we can learn of any potential pain points from the client perspective, and how we can constantly improve our process. It might seem like a waste of time for some, but we find that it allows us to move much faster overall-
Here’s a nice quote from Retrospectives.com
“Regardless of what we discover today, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” Retrospectives.com
Burn Down / Burn Up Charts
Here’s a “Burn Up” chart that we deliver to clients if they ask for it, or if the product is already in the market (and our iteration cycles are much shorter) It shows how many points that we’ve completed over the lifetime of the project and what was accepted by the product manager.
Here’s a ‘burndown chart’ that shows how many points we have left on the project before our “Release Blocker” combined with how many points we are completing per week. So, for the above example, it looks as though we should deliver either on May 1st, or before.