As a team transitions to using Scrum and Agile, finding the proper sprint duration is likely something they will not give enough thought to. The team will likely just pick an arbitrary duration and set about to make that work. That is certainly one way to do it, but there is a real danger that this initial sprint duration becomes the norm without a second thought. I would caution against this idea. I find that it is important to understand how the scheduling works for sprints, and what a sprint of a given duration actually contains.
This blog is a continuation of the blog that I wrote about the importance of difficulty based estimations in the sprint process. In that blog, we covered how I feel it is important to distance the team from thinking in terms of time and to think of difficulty instead. Naturally, the next question to answer is: “How do I use those metrics to measure the burndown, and to a greater extent, the velocity of the team?“
We all know the feeling. You sit down in a Sprint Planning meeting and a project manager walks in. The instant that he sits down you can tell there will be some tension. He wants to do it. He is compelled to. He will absolutely try to force real world hours on your estimations. He lives in a world of black and white and the only justification of the work that you are doing is measured in time. He will take your Story Points, and turn them into something they are not. Time. If you can empathize with the story above, you are not alone. This blog post will talk about tackling the ideology change I believe is needed to ensure accurate estimations.
As technology continues to advance and more companies start to see the need to stay up-to-date on the “newest and latest,” the more I have become invested in researching ways technology is starting to impact roles in the workforce. As I dug deeper on Continuous Integration to elaborate further on my previously explored “DevOps” path, I stumbled upon this great concept referred to as “Infrastructure as Code” or “Programmable Infrastructure” and it really peaked my interest. This blog post will cover a high level description of Infrastructure as Code and how developers can start taking advantage of it while incorporating it into their everyday tasks.
As a first-time conference goer, September 7-11, 2015 was a whirlwind! I met marketing professionals ranging from Australia, Florida, Montana, and even my native Washington, DC. I attended spotlight sessions from famous authors (cheers to you Jon Ronson) and even cracked up at a stand-up session by the ultra-hot comedian from Trainwreck (that's right, be jealous - Amy Schumer).
So what conference did I attend, you ask? Well, Hubspot's annual Inbound in Boston, MA, of course! So as you can guess, and probably correctly, all thousands (yeah... 14,000 of us) who attended are writing blog posts about their experience and what they learned. While that's great, I want to be unique and write about how I can take my newfound Inbound knowledge and apply it to something from the fantastic software developers I work with here at Easy Dynamics... and that's Agile.
Scrum, the most popular Agile Process according to Kenneth S. Rubin's bestselling book on Amazon ‘Essential Scrum’, helps teams create a more efficient methodology through an iterative and incremental process. A major goal for any business is to not only satisfy the customer, but also keep them happy. By following these simple SCRUM guidelines, a team will always put a functioning, quality product in its customer's hands after every sprint, therefore keeping them happy.
Team Foundation Server is an Agile tool that can help you organize your daily activities such as tracking big picture items as well as smaller ‘to-do’ tasks. I use TFS to track .NET software development projects, but I decided to try it to plan my daily activities for today's blog post. Read further to learn how I created a TFS process for everyday use.