You’re gotta have to serve somebody…

Final Project
We’ve been blessed. We actually have a real client. The Final Project is all about simulating a real project and the creation of an application, but we’ve been lucky enough to not have to simulate. This is real. Well, with the exception that out there in reality I hope that I will actually get payed…
Our client’s called Venue. A sort of crowdfunding-service for Artists. By selling early bird-tickets in Campaigns to proposed events, the Artists can fund the Event if enough people buy tickets. This way the Artists and Event-organizers don’t have to book expensive locations and end up with an empty “venue” and subsequently; no money.
So this is it! We’ve started the Final Project!
Design Sprint
By now we shoulda somehow, realize what we gotta do, so we obviously started of with Design Sprint-days… We started of this Saturday, exactly two weeks before our Graduation Day.
Like addressed in previous blog-post, we came to the conclusion during the Retro last week, that we have a problem being consistent in our Agile approach. “Meassures were taken” and I got the idea of setting up some rules and guidelines for the Final Project weeks. Nothing fancy, more like rules of the common sense-persusasion…
As a Dev Team
In order to maintain consistency
We will set up some daily, and general Sprint-rulesScheduling, meetings and participation
1. At 8:30am we will have a briefing for the Scrum Master before the general Scrum
2. At 17:00 (5pm) we will have another briefing to go through what will be done during the night.
3. At 20:00 (8pm) we will have a Hangout-session running as short or late as the team member feel and depending on who are working together.
4. On the one weekend we have (the 8th and 9th) we will have a Morning Scrum at 10:00am both Saturday and Sunday.
5. We will have a optional hangout during the evenings at the 8th and 9th.Workflow and Gitpong-ing
1. The SCRUM master will be in charge of deciding whom are working on what PR.
2. At least 2 people, not including the Scrum master, shall review each PR. This means the owner of the PR will ping the Scrum master and at least 2 people, on both PT and Slack whenever a PR is no longer a [WIP].
3. We will work no longer than one hour on a PR before switching up our 1/2-working structure. The person working on his/hers own will jump in as the new driver in the pair-team, and the navigator in the pair-team will take over the “single working” pr.Pivotal Tracker
1. The Scrum Master will be in charge of the PT. No edits to the PT are allowed without the Scrum Masters approval.What we expect from each other
1. Scrum master will ask team members whether they would want to do a PR or not. Once accepted we as team member expect that it gets done. Help will be given if asked for.
2. Everyone can run late, but we as team member will avoid making this a habit. If you can’t make it to an obligatory Scrum or briefing, the team member shall join remotely.
3. Any kind of other obligations during these weeks should be mentioned as early as possible.
4. As a gesture to our fellow team member, we will in the longest always try to prioritise the project first and foremost.Sprint Briefing and Review
On [Date] we will have a briefing with our Client to go through what we have done so far.
The Scrum Master will be in charge and will deliver task to the other team members to explain certain part of the application.SCRUM-master
1. We will switch SCRUM-master every other day.
I also took the initiative to start writing Daily reports.
This has already helped us a lot during the first days. We’re more disciplined, more precise and have a much better overview of what’s going on.
We had a Scrum briefing at 8:30, were we briefed Tetiana, who was back from her other commits with Sthlm Tech fest, on what Erik and Andy had been working on during the Sunday and Monday.At 9:00 we had our Morning Scrum were we made sure that we got a room booked for today and when we were suppose to have our first Career talk.At 9:30 our Clients showed up. We started with going through and present every single User Story we had so far, and then we started our two first voting procedures. In total we made four voting procedures during the day.We made a decision to end the Design Sprint at 14:30.
We had our first Career talk and then went to work with our first User Stories.
Andy made PR #8 for “Guest can create a Campaign” and Tetiana made the PR #9 for “Guests can view Campaigns on the landing page”.
After some unexpected initial problems we eventually got it to work and the test went green. We hade some SemaphoreCI-problems swell that was fixed with some help from Magnus.At the briefing at 17 it was decided that Tetiana would get the night off and that she instead will go up early and continue working on hopefully a new PR.We had a lot of comments from Thomas on the earlier PR’s which was addressed during the /hangout-evening-session. We still have some major styling-issues that needs to be resolved.
The Design Sprints went on quite good I have to say, and in total we produced a bit over 30 User Stories. As the week progressed and we actually started coding we noticed that we were impressively accurate in terms of when the User Stories is supposed to be implemented. We know the work-process and understand that “this and that” is needed, to take us to “this or that point”. This type of understanding makes us able to first and foremost focusing of implementing features that goes well in hand with the MVP.
Knowing that this is a really short and intense Sprint; one of the most important thing for us as the Development Team, has been to manage the expectation of our client. We can come up with a 100 features and User Stories and that would all be fine and dandy, but realistically we all know that even a real experienced and well working Development Team would most likely not be able to do that. This is our first real project ever and even though we work in a much faster pace than a Development Team usually do, we will still not be able to do a complete, fully functional and ready to launch Application…
We expressed to our client that they must count on not having a finished Application in two weeks, however if they realistically and objectively look at what three unexperienced, soon to be Junior Developers, would be able to do in two weeks; they will probably be surprised of how much we will actually manage to do… With the right expectation I am sure that they will be very pleased with what I think we will achieve.
For me personally it’s a bit hard to be in a situation of still learning and develop my skills, but at the same time have to serve somebody, and deliver…
On one hand it’s kind of annoying to not really be able to focusing on the learning at this point, because you have to deliver, while on the other, it is stressful to feel like you don’t really deliver enough, because you are still learning… Well, I’m surely not the first person to be stuck somewhere in the middle of being young, hungry and desperately want to achieve, and being to unexperienced to do so.
