Day 8. First demo

At the start beginning of our morning stand-up it seemed, that most of our stories were completed, but during the discussion it turned out we still had some features to add.

We started work on the features without too much panic, because the sprint demo was at 3 pm. With the tasks related to the sprint demo being in progress we tried adding some functionality from outside of the scope of this sprint. Our mistake in this was, that we also tried changing the part, that was in the sprint. This caused a big part of our system to have buggy implementation 2 hours before our first official demo.

This meant that it was time for our first hotfix, to restore the previous functionality in time for the demo. With this done we had an introduction to Jira for our next sprint.

The demonstration was up next and after a nervous start everyone got the gist of the story and our Product Owner had to decide if she accepts the story or not. I'm happy to say all of the stories presented were accepted.

With a successful sprint behind us it was time for our retro. As we stickied our ups and downs during the sprint we had some patterns emerging. On the positive side our teamwork is good. On the negative side.. Oh boy.. If Estonians are known to be critical of things, then in this sprint even our Georgian teammate ran out of red stickers. The conclusion for the bad part being : Task planning, Different views on programming, Code quality, Testing.

The last thing we did was discuss our codebase and decided to add The Repository Pattern to our existing codebase and refactor the existing codebase.

Day 7. Lucky number 7 they say..

Today our day started with the stand-up becoming easier and more informative at the same time. Our team is getting to know each-other and it feels great.

The bane of our existence has been implementing a file attachment feature. There is an existing one, but that just makes the decisions harder. Should we use the existing one? Should we use a hybrid? To even attempt to answer this, you have to understand the existing code. This is something that makes my head boil, as writing code is hard enough, but understanding why someone else has written their code in their own special way is just that extra nudge, that makes you want to take a breather for 15 minutes.

What can be worse is to struggle with a problem for the longest time and then find out you just mistyped the name by a character or forgot to pluralize a list and after an hour of searching you see it and a wave of relief washes over your followed by a tsunami of shame follows for making these dumb mistakes. Luckily the IDE catches many of them, but the mighty IDE  cannot always save you.

To cool off, we had a nice little team game planned to grow as a team and see how we interact with each-other, when there is a lot of room for interpretation. The task was to decide what should happen with 4 people marooned on an island if they had built a ship, that would be only able to sustain 3 people. The limited information given was that those 4 people were : A shipwright, a doctor, a genius and an extremely wealthy individual.

Our discussion went on for a full hour and in the end, we still didn't agree, with 4/5 people in our team deciding on casting out one person and our last team-member sticking with his choice. But that didn't matter, as I felt that we as a team became more open and everyone got to voice their concerns about the predicament.

I enjoyed the viewpoints my teammates and appreciated the reasoning behind them.

Today was a great day

Day 6.

A new week and we're standing up in the morning again. Ah the stand-up meeting, remembering what you did on friday can be a struggle sometimes, especially with a busy weekend.

With the static views of the tasks being done we are now trying to create some dynamic fields to make it a little 'snazzy' for our users. This is proving to be a much bigger challenge and more time consuming  than initially predicted. But then again, it's more unique, which makes for a great learning opportunity.

The tasks are slowly, but surely inching their way to completion, with some more problematic ones rearing their ugly heads at us and giving us a hard time.

Day 5

We had our first sprint stand-up today! This was new for everyone on the .Net team, but as the concept was simple and communication good, we had no issues with it.

With the first sprint planning being quite thin on user stories, we struggled with choosing tasks that didn't depend on the previous tasks or were ready to be taken on. With limited tasks and unlimited brainpower, we settled on coding in pairs with one person coding and the other observing and vice versa.

The day itself was quite productive, but hasty errors proved to be tough to crack, as the first commit made dealt with a similar issue as the last commit.

One does not simply git push

At the end of the day we voiced our concerns about the bootcamp, the milieu, the people or anything we could think of. All of the feedback was positive and everyone was content.

I for one was exhausted when the week ended, with my mind buzzing with new information.

Day 4. Software architecture and our first lines of code

First thing in the morning our mentor Markus gave us a quick overview of software architecture and demonstrated them with some practical code. He made some good points about code reusability being dangerous when the need comes to alter the codebase. And warned against leaving vulnerabilities in your accessible layer.

Our first sprint planning was a joyful endeavour as we were getting so close to starting to write some code and starting to fulfill the plans made for the last 4 days. With some back-and-forth with the client we managed to create 12 user stories. Assigning story points was a fun and slightly odd experience as during the first sprint planning meeting the story points value is still wildly inaccurate. In the end we decided to take 10 user stories into our first sprint.

After some confusion about splitting up the user stories we managed to get our first stories and tasks on the scrum board. This meant we could take a task and start developement! Right? Well almost, we still had to create the underlying data model. So we split into teams and half of us started work on the view and half of us on the model. It was strange working with multiple people on the same problem as there was more explaining and questions, time will tell what will come of this.

In the evening we had a pub event with our bootcamp team. So this was us arriving there.

We filled out 3 tables in a cozy bar called Kivi Paber Käärid. The mood was relaxed and it was nice to chat to the employees of Helmes without the subject being about the bootcamp. We taught our foreign teammates some Estonian classics such as counting to 12, teaching them how to pick up girls. All in all a great evening!

Day 3!

Agile development and Scrum

The day started with creating vision for the UI based on the information gathered in the client meeting yesterday. Armed with our notes we started hashing our the fields and views to our best ability.

With a baseline design done we were joined by our helpful clients and analysis team, who helped us phrase high level business requirements. In order to do this we had to define a series of points, that would end up helping us form an elevator statement and business goals and their metrics.

The task was not easy

First off we  determined who would benefit the most from our application and they would be our client. Secondly we identified the need, for which they needed to use our application. Then we had to have a great product name for our creation and classed it into a product category. A big aspect was the list the key benefits, that our solution would provide. And to finish off we described what would be unlike the current process e.g. make the process less time consuming and create less errors.

Discussion is key

Don't forget to document your decisions 

Make sure the whole team is on the same page

Afternoon began with a seminar about agile development and Scrum. It was a free-form lecture conducted by Raul Annus, the head of development in Helmes. We started of the lecture with the question why agile development is needed and what makes software development so difficult. In the end we managed to word in our own words a few points :

• Environment changes fast
• Very many dependencies
• Software is only a representation, not the real thing itself
• Software disrupts the business process

In conclusion we ended at the realisation, that there is never a perfect analysis of the problem and that making something faultless is limited by us being human and making mistakes. In agile you have to make a small usable product and actually test it within the business process as a whole. But in order to build something useful you still need to align the strategic business goals and the business needs, only the features have the luxury of not being right 100% of the time.

After a small break we had a meeting with our stakeholders and intruduced our UI to them. Showing a mock-up of the UI got the team leads creative juices flowing and we got a good idea of what the UI would look like in a perfect world. 

Day 2!

The dread of meeting with the client

The preparation

Day 2 started with an analysis seminar, where a Helmes analyst Kaisa gave us some tips on what to do when meeting with the client. Some notable advice was to keep it simple, produce a MVP and don't promise things you can't deliver.

After the seminar we had our analysis mentor helped us to create a questionnaire to maximize the time we had with the client. The questions used the following guidelines:

• WHO (who is the client?)
• WHY (why are we doing this?)
• WHEN (what are the timelimits?)
• HOW (platform?, existing code?, analysis process setup, communication?)
• WHAT (the actual business requirements and functionality of the system, what is the actual need of the client)
• PROBLEMS (what would be their priority: minimum viable problem)

Constructing the questions was no easy task as we had not worked with clients before so coming up with the business process questions was an unfamiliar activity.

Photoshoot

Before meeting the client we gave a photographer the wonderful opportunity to make some software developers smile. 

As seen on the photo below everyone enjoyed themselves and the photographer didn't have a hard time at all!

The meeting

The meeting with the client started with everyone introducing  themselves and their role in the project. With the introductions over we hunkered down with our questions and started trying to get the information we needed from the client. Our initial plan was to ask about the high level idea of how the current business process worked and what the problem with it was. Having asked the question we were barraged with information about what the problem is and how the new system should fix it. This may have been due to me asking the question we had previously written down more palatable. There's a lesson in this, make your questions clear and concise and perhaps take your clients background into account as the client was knowledgeable about the system and it's requirements. Thanks to a great scribe we managed to get a lot of information about the specification. 

The second surprise came when about 1/3 of the way into the meeting I realized I had completely misunderstood the problem. You see, I thought we were to make a system that creates and saves contracts. This was due to my poor understanding of the project brief given to us earlier. Actually we were creating a system that added some metadata to the contracts to make them accessible. With a flustered face I kept calm and carried on.

After the meeting our mentor said the data we had gathered was good and the meeting went very well. We systematized our notes and headed home for the day.

1. day! Introductions and workstation set-up.

Introductions

The bootcampers with Helmes staff

On the first day at the Helmes Bootcamp we met the two teams in the bootcamp and the bootcamp team, who will help us on this exciting journey. We had a introductory meeting and saw and met all the people  who will be directly interacting with us. The mood was light and everyone was friendly. We also got an overview of the core values of Helmes with the uplifting slogan of "We want to be the best software services firm in the world.". True enough, the inquisitive mind of the bootcampers wanted to know, how being the best is measured and the answer is by employee happiness, client happiness and efficiency.

The aim of the bootcamp will be to offer an intensive software development training, see what Scrum is in practice and to complete a full software development process. The evaluation criteria for the bootcamp is surprising compared to the aim with 30% of the evaluation coming from the result of team work. Helmes really seems to value interoffice relations. Achieving business goals will determine final evaluation by 25%, following Scrum principles 20% and code quality and successful sprints attribute 15% and 10% respectively. So coding proficiency is not the most important aspect by a long shot.

The teams and projects

This year there were 2 teams taking part in bootcamp: a Java team and a .Net team.
Projects for this year were Licences allocation and Applications Accesses and Contract Register. The Licences allocation and Applications Accesses focused on managing licences that are distributed within Helmes and aimed to help managers free up unused licences. This project was assigned to the Java team. Contract Register aimed to add a new module to an existing application, that would help Team Leaders manage contracts. A clever person would assume this was the assignment for the .Net team and they would be right!

The setup

After the introduction of the projects it was time to set up the workstations and attempt to get our first commits to the development repository. After installing all the prerequisite software the .Net team ran into a problem with connecting to the development database and we were unable to verify that the base application worked. Java team did not have this problem and they were off to the races, learning about git commands that they had not used before. While the Helmes staff debugged the problem with the connection we got some tips from our mentors and I personally learned, that more often than not, if you don't build logging into your application as you build it, you will never add it afterwards.

That was it for day 1!