This developer's chronicles

Web development using Scrum, C#, AngularJS and the like

Category: Scrum

How a coding bootcamp boosted my professional career

I recently completed an intense 9 weeks coding bootcamp called FireBootCamp at SSW’s office in Sydney and today I wanted to share my experience about how it changed my perspective about software development as well as to hopefully encourage people out there (who are looking for ways to improve their skills) to go ahead and join one.

Why join a bootcamp?

Technology in general changes at a very rapid pace and specially if you are a developer you need to be ahead of the game, some of the things I’ve done to try to achieve this are:

  • Read blog posts and tutorials about -insert language here- and new frameworks -insert framework name here-.
  • Watch hours of Pluralsight videos.
  • Follow influential people on Twitter.
  • Attend different usergroups.
  • Work on personal and open-source projects.
  • Practice, practice and more practice.

While all the above has greatly helped in my short career I felt that something was missing, I knew I could build things that worked but I was mostly copying someone’s code without fully understanding what was going on or why things were the way they were.

This is where the bootcamp fitted perfectly in, it did not only break things down so I could digest them easier but it also showed me the big picture and provided me with enough exposure to problems (and ways to solve them) that everything clicked and started to make more sense.

What is SSW’s FireBootCamp?

SSW’s firebootcamp is the best way to increase your skills in an incredibly short amount of time, it’s 9 weeks where you’ll  learn better ways to build maintainable and scalable software, better ways to improve as individual and enhance your communication and presentation skills and better ways to collaborate with your co-workers, clients, product owners, etc; and all that while using the latest and coolest technologies!

A rough overview of what we saw during those 9 weeks is below:

  • Scrum: This was probably one of the biggest take away for me, we learnt how to inspect and adapt to the ever-changing software requirements, how to deliver software faster and continuously by getting early and regular feedback from the product owner and stakeholders, and by following the Scrum guide and all its events.
  • Enterprise architecture: We developed a real application using the Onion Architecture, but most importantly we looked into why it was important to have an architecture, its pros and cons and how to future-proof your applications.
  • Patterns and best practices: We covered a great deal of patterns  and best practices aimed at building more robust applications, some of them were Inversion of Control and Dependency Injection, the repository pattern and SOLID principles.
  • Full stack development: Not only did we dive into ASP.NET MVC 5 as back-end framework but we also covered Web API and Entity Framework as well as AngularJS and Kendo UI on the front-end, oh and how to forget TypeScript !.
  • Continuous Integration and Continuous delivery: Deployments were one my biggest pains of all time but we learnt the right way to do it by integrating TFS (Visual Studio Online) as a tool to automatically build our code and run unit tests against it with Octopus Deploy to automate our deployments to Azure.
  • Soft skills:  also one of my most improved areas as I realised how important this is for our success. The days were developers sat on a dark corner are long gone so if you want to be successful you need to be able to communicate effectively and clearly (we had a lot of practice on presentation skills and how to market ourselves as developers; that is why I started writing this blog after we watched a video by John Sonmez).
  • Talks by industry leaders: Once a week we would have speakers come and talk to us about different technologies, we had Andrew Coates talking about Azure, John Bristowe from Telerik, Paul Glavich talking about WebAPI and SSW’s Duncan Hunter with TypeScript, Adam Cogan with Scrum and last but not least our awesome mentor Gerard Beckerleg from whom I learnt the most.

I’m sure I am leaving a lot of interesting stuff out but you’ll hopefully get the idea of what this bootcamp is about and how it can help you increase your skills.

 

Final day and presentation

As if 9 weeks of coding and learning better ways to craft software was not intensive enough we were also asked to give a talk on the last of day of the bootcamp about a topic we really enjoyed and which had been beneficial (and it was in front of potential employers!). I chose Continuous Integration and Continuous Delivery with TFS and Octopus Deploy as it really took the pain out my deployments, below is a picture of my presentation !

Continuous Integration - coding bootcamp - SSW Harold Rodriguez

So if you are serious about your career and are looking for a way to increase your skills then SSW’s firebootcamp is the best way to achieve it!.

I’d love to hear your comments or if there is anything you’d like to have included in this blog post let me know.

Sprint Planning afterthoughts and retrospective

Updated on 17th February 2015: Added list of items that I consider went well on our first Sprint planning ever and also what we could have done better.

 

We had our first real Sprint planning session at the FireBootCamp today and I have to admit it that it went relatively smooth compared to what I thought it would be (mainly due to our inexperience).

After looking back at what we did (and didn’t do) and based on the Scrum Guide and the feedback provided by the Product Owner I have put together a list of items to improve on and also at the end of the article some good things to consider when you are planning your next Sprint planning !

 

What we didn’t do that well…

  • The Scrum guide dictates that one of the outputs of the Sprint Planning is to set the Spring goal: unfortunately we didn’t specify clearly what our goal was other than the full completion of the Sprint backlog.
  • The Scrum Master ensures that the event takes place and that attendants understand its purpose: We lacked of communication with the Product Owner (or at least it could have been a lot better) and even though the Scrum Master (myself) explained what the meeting was about and was reminding everyone of the time with a bit more preparation the results could have been better.
  • Plan for delivering the Sprint goal was not fully established: Even though we came up with the selected PBIs for the first Sprint were were unsure of how to estimate effort and how to organise the tasks to be completed (we ended up completing this task the day after the Sprint planning meeting happened.

What we nailed !

  • Sprint planning events are timed-box to a maximum of eight hours for a one-month Sprint: as we have one-week Sprints we stuck to a two hours Planning session (we took less than that)
  • The work to be performed in the Sprint is planned at the Sprint planning: as we had worked on our possible PBIs for the Sprint we were really ahead on this one so we came up with ideas about which tasks we believed should be part of the first Sprint.

 

Tips for your next Sprint planning

  • The Development Team will forecast the functionality to be developed: It’s always good to plan ahead and by researching the tasks/features that may be implemented in the next Sprint, the Development Team can perform better at forecasting the next PBIs to complete and also they will have more time to ask questions to the Product Owner about the known unknowns (and unknown unknowns).
  • Ensure the Development team has a good understanding of the specifications:  Anyone from the Development team should have a good level of understanding of the specifications of the product to be built so they can contribute if required (specially in cases where the Product Owner has requested that the Development team comes up with the Product Backlog Items) in the same way that they can seek clarification from the Product Owner on unknown/complex topics
  • Create mock-ups and have them ready: Mock-ups are a great way to solidify your understanding of the product and visualize show what you want to build as well as getting instant feedback from the Product Owner on issues that you may have overlooked, it’s very important that you also get the Product Owner to initial it (so that they check the mock-up again), see additional info about conducting specification analysis by creating mock-ups.
  • Coordinate who is going to take notes of the feedback provided by the Product Owner during the Sprint Planning so that they can be evaluated at a later time.
  • Make sure the next meeting is coordinated with the Product Owner at the end of the Sprint planning:  Product Owners are busy most of the time so what better opportunity to set up a meeting than at the end of one?
  • Contact the product owner prior to the meeting: this will let them know that they are important and that you haven’t forgotten about the meeting, it will also confirm the appointment so you know that they will attend.
  • Make sure your Scrum Master addresses the Scrum Team by:
    • Explaining the purpose of the meeting
    • Explaining the agenda for the meeting
    • Explaining that this event will be time-boxed (and how long it will go for)
    • Explaining what the expected outcome of the meeting will be.
  • Make sure the Sprint goal is set once the Development Team and the Product Owner agree on the PBIs that will form the Sprint Backlog.
  • Finally, ensure that the Development Team clarifies to the Product Owner and Scrum Master how it intends to self-organize in order to achieve the Sprint Goal.

 

I’m sure there are plenty more things to consider prior to performing a Sprint Planning, Which ones would you recommend?