What's Scrum?

Scrum is a Better Way of Working

Scrum is for sure a better way of working. Above all else, Scrum is an agile project management framework which provides only a few rules. It reduces risks, maximize return on investment, and tells the very truth about the project and its evolution. The metrics used to measure the team's velocity brings in another point of view upon the product development and allow for a more precise long-term view over the project development.

Foundation of Scrum

"In 1995, Ken Schwaber and Jeff Sutherland presented the Scrum Methodology at the Business Object Design and Implementation Workshop held as part of Object-Oriented Programming, Systems, Languages & Applications '95 (OOPSLA'95) in Austin, Texas, its first public presentation." (wikipedia.org)

"Scrum is a simple framework for effective team collaboration on complex projects. Scrum provides a small set of rules that creates just enough structure for teams to be able to focus their innovation on solving what might be otherwise insurmountable challenge."

(Scrum.org)

The Scrum Team

The Scrum Team counts three major roles:

• Scrum Master, responsible for applying the rules of Scrum
• Product Owner, responsible for the best return on investment (generally the customer)
• Development Team, responsible for the implementation of the required features

Altogether the Scrum Team is responsible for the success of the project and the best return on investment - on schedule!

The Scrum Master

The Scrum Master is indeed responsible to apply the rules of Scrum, and that is:

• Removing impediments
• Guiding the Development Team in its decisions in a Scrum point of view
• Guiding the Product Owner in its role
• Writing the Sprint Retrospectives
• Writing the Sprint Reviews
• Measuring the success of the Sprints based on predefined Scrum metrics
• Informing the Product Owner and stakeholders about the evolution of the project
• Accompanying the Development Team in order to improving its way of working
• Helping the Product Owner, the Development Team and the stakeholders to understand the Scrum software development process
• Emphasizing direct customer communication
• Making sure the Scrum time-boxes are respected (Sprint Planning Meeting, Sprint Retrospective Meeting, Sprint Review Meeting, Daily Scrum Meeting, and the Sprint itself...)
• Guiding the Development Team in evaluating the user-stories' complexity
• Proposing some strategies to reduce the risk of failure
• Guiding the Development Team in estimating the tasks
• Planning the Development Team availability

The Product Owner

The Product Owner is responsible for the return on investment, and in many occasions the acceptance criterion:

• Defining the features
• Writing understandable acceptance criterion
• Bringing further details to the Development Team when required
• Prioritizing the features in the Product Backlog
• Assuring the best return on investment
• Gathering responses for the Development Team that it cannot find for itself
• Assisting to the Daily Scrum whenever possible (not obligatory and very encouraged)
• Participating to the Sprint Review Meeting
• Accepting, along with the stakeholders, delivered pieces of product at the Sprint Review Meeting
• Participating to the Sprint Retrospective Meeting
• Deciding whether a story may be accepted as Done when presented during the Sprint Review Meeting

The Development Team

The Development Team responsibility lies on, well, the development of the required features which in return encompasses:

• Evaluating user-stories complexity (aka Planning Poker)
• Estimating the tasks in hours (or whatever has been decided by the Team)
• Committing to deliver functional pieces of product by the end of the Sprint time-box (based on the number of story points evaluated)
• Defining Done, along with the Scrum Master and the Product Owner so that only one definition is used throughout the project
• Documenting its work
• Writing acceptance tests based on the acceptance criterion
• Testing the developed features to meet with the requirements and/or acceptance criterion
• Creating the tasks required in order to achieve the user-stories
• Developing the features
• Preparing the Sprint Review to present the completed stories to the Product Owner and stakeholders

Embrace the changes

The more complex the project, the more changes it brings. Any changes are to be adopted whenever possible - the sooner the better.

If any change occurs, this means an occasion to be flexible to what the end-customer really needs. Planning exactly what you'll need in month from here is quite impossible because you don't know where you'll be in a month!

Software development is a very complex profession for one must fully understand the business domain of his own field of activity, and on the other hand, have a great understanding of the business domain of the customer. That is hard-work!

The changes may come from a sudden change of mind from the customer himself, or from the Product Owner priorities. Changes might also come from the Development Team which during the development process learns more and more about the business domain of the end-customer, hence some early decisions which no longer make sens later on.

Transparency

Ostriches are rather unwelcome in the Scrum Team. Scrum requires above all else transparency, honesty. If for a reason or another you're not about to meet with the schedule, then say it sooner or later. That way, everyone including the Product Owner may work on expectations and at least understand the real situation, the real problems.

Over the years I have learned that people can understand, when they are given the right information to allow them to figure things out. That is one reason, among many others, why I like Scrum.

Speaking of transparency, this also means that the stakeholders can see the evolution in real-time of the project. Be it special tools or a simple charts in a conference room, the Development is responsible to give the right information about the project evolution and obstacles it goes through.

Waterfall against Agile

The major difference between agile methodologies and the others like the Waterfall approach is that Agile digs it vertically, that is, the Team works on every aspect of the project during a predetermined time-box, the Sprint, where the analysis, the architecture, the documentation, the tests and the demonstration to the stakeholders are all done. 

On the contrary, the Waterfall and traditional approaches do all of the analysis, all of the architecture, all of the development, all of the tests, and finally all of the documentation. Whenever a step is compromised, the preceding takes over until it is completed again with the newly gathered information. This ends with never-ending stories and both supplemental costs and time. Often when the product is delivered to the end-customer, it no longer reflects the reality since the portrait has been taken months and even years ago. 

Summary

For sure it is impossible to include everything of what is Scrum in a single blog post as many many books have been written on the subject among multiple training all over the world. I shall then write again about Scrum and cover elements which couldn't be covered here.

Thanks for reading!

What's Agile?

We all have our definition of the word "agile". We might as well say agile as a cat! But what does this mean in the world of information technologies? Here's my answer to this question.

First of all, if you think Agile is new, you're mistaken! The Agile manifest was signed back in 2001 by a group of IT professionals who are known worldwide. Herewith from the Agile Manifest on Wikipedia:

"In February 2001, 17 software developers [...] met at the Snowbird, Utah resort, to discuss lightweight development methods. They published the Manifesto for Agile Software Development to define the approach now known as agile software development. Some of the manifesto's authors formed the Agile Alliance, a non-profit organization that promotes software development according to the manifesto's values and principles."

The professionals who reunited are the following:

Kent Beck

Mike Beedle

Arie van Bennekom

Alistair Cockburn

Ward Cunningham

Martin Fowler

James Grenning

Jim Highsmith

Andrew Hunt

Ron Jefferies

Jon Kern

Brian Marick

Robert C. Martin

Steve Mellor

Ken Schwaber

Jeff Sutherland

Dave Thomas

The most well-known among them were Ward Cunningham, inventor of the Wiki via WikiWikiWeb, Kent Beck, father of the extreme programming and co-founder of JUnit, Ken Schwaber and Jeff Sutherland, founders of Scrum, Jim Highsmith, extolling ASD, Alistair Cockburn for the Crystal Clear method, Martin Fowler and Dave Thomas as well as Arie van Bennekom for DSDM (Dynamic System Development Method), and Robert C. Martin (aka Uncle Bob), father of Clean Code.

From these software development professionals are born the following agile values:

• Individuals and interactions over Processes and tools
• Working software over comprehensive documentation
• Customer collaboration over Contract negotiation
• Responding to change over Following a plan

Individuals and interactions

"In agile development, self-organization and motivation are important, as are interactions like co-location and pair programming."

This doesn't mean that Agile throws away any processes and/or tools you might be using, this simply means that Agile encourages and emphasizes on the team members interactions and self-organization. Trust your team!

Working software

"Working software will be more useful and welcome than just presenting documents to clients in meetings."

Though documentation is an important matter, even in Agile Software Development, Agile doesn't focus only on the documentation and tends to shorten the docs a bit and prefer to deliver working piece of software instead of just sentences on a piece of paper.

Customer collaboration

"requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important."

As for sure, as you the customer, and as us, IT Services Companies, we want some sort of warranty where everyone wins. Hence contracts are important for businesses to write. Aside, there is a need for trust between those two because software development is pretty much of a complex task. And in order to get exactly what has the most business value for the customer, the development team needs to have regular feedback from the stakeholder(s) so that the development process may evolve and the software be delivered in no time. This discourages the way many software companies still work today, that is, letting the development go for weeks and months before the customer even sees the product, and might finally bring breaking changes because of the lack of communication between the two.

Responding to change

"agile development is focused on quick responses to change and continuous development."

The customer's needs can change along the way, or requirements might have been initially misunderstood by the development team, and even the thoughts about the product might change! Hence the quick response to change. For this to happen, in addition to customer collaboration, we need to provide regular feedback to the customer so that when a change requirement occurs, the development may adapt the product according to these changes as soon as it is known, for the sake of the project and the stakeholders.

In the end, Agile is all about delivering functional high quality software that meets the exact customer requirements at the time the product is final, by reducing and controlling risks taken over along the project by both the customer and the software company and to make sure that the delivered software meets the customer satisfaction and that it has business value to allow the best return on investment.

My Story, where it all began

In my last post, I said I was to write a bit about me so that you get to know me better. So here it is.

When I graduated in 2005, I had already started to serve residential and commercial customers by offering them on site technical support. From 2005, I offered my services as an employee to IT companies around the city, Shawinigan and Trois-Rivières, QC, Canada. Yes, I had the diploma, but I hadn’t the experience, so no employer was willing to give me a chance. I then decided to take the bull by the horns and founded my own enterprise in Febuary of 2005. The next month, be it the 25th of March 2005, a big fire burnt my entire residence. This was a total loss. With the help provided from family and friends I bought my first furnitures, a work desk and a computer.

In October 2005, I learned that a transport company needed a management software badly. Let’s call it ABCT. I offered my services and about 7 months later, in summer 2006, a friend and I delivered the first pieces of software required for the company to work with. Of course, I didn’t know about Agile methodologies back then. About a month later, the office clerks had gotten used to work with my software, Transport Manager, and finally were able to perform with only two clerks more than the work performed with three clerks, because of some of the business flow improvements I had suggested. This represented an economy of about 45 000,00 $CAN per year. Keep in mind that this was my first at all contract! Quite a frank success for a young entrepreneur and unexperienced IT consultant!

Then, came the wood economy crisis that severed in 2007, and ABCT bankrupted. I went back to propose my services to places where I was refused back in 2005, and I finally got a job as a programming trainer at a private IT college in my area. I discovered a new passion, knowledge sharing! I loved the fact that I was sharing my knowledge and experience to students from whom I learned a lot of interesting things! I wonder if they did learn as much as I did during these training sessions! When this college stopped the program, I moved along and got another job as an analyst-programmer for Alcoa Canada - Primary Metals. I have worked there from 2008 to 2009 before the economy crisis severed even more letting Alcoa no other choice than to reduce by 15% the hours worked, so I was thanked by the way and decided to come back with my company for which I fulfilled many other needs for the Quebec government and other private corporations such as Bridgestone, Bell Business Markets and others.

In 2010, I had the great opportunity to meet with Ken Schwaber himself, co-founder of Scrum and founder/president of Scrum.org. I have taken his class to become a certified Professional Scrum Master. My first project using Scrum was a hell, since I didn’t master Scrum that much, and between theory and practice, there’s a world of difference! Now that I master it, I wish to share some of my Agile Adventures with you.
In 2013, I decided to change my company brand name for something a bit more serious, Société Groupe Conseil WMI (which would translate as WMI Software Consulting Group), and here I am today!

Now that you know me better, I believe that I have some knowledge to share as both an entrepreneur and an IT professional. That is this blog’s purpose. I do hope you enjoyed learning a bit more about my story and that this will inspire others.

Thanks for reading!

My name is Will Marcouiller, founder and president of WMI Software Consulting Group.

This blog is to share my passions: entrepreneurship and information technologies (IT). Although I have other passions such as mini-mechanic and power-sports and may write about this sooner or later, I'll mainly focus on IT.

I called my blog "Agile Adventures" because of the adventures I went through when I got more and more acquainted with the Agile methodologies. So I shall use this blog as a learning diary where I'll be sharing my learning. Indeed you are invited to comment and to ask question about any topic. Together we may grow stronger in our knowledge by sharing on interesting ideas.

In my domain, I have a great interest in the Agile methodologies. I love the simplicity and the ease that Agile brings in the software development industry. Because IT has no authorities, certifications and private corporations gives you more credit than being a member of an engineering order. Sometimes, we have a hard time knowing what's good and what's not, always asking questions about best practices and looking for gurus such as Eric Lippert and Jon Skeet, Robert Martin, Ken Schwaber, just to name a few. Here, I want to share my own knowledge so that I may learn from the others who are willing to share theirs.

In my next post, I shall introduce myself accordingly to say where I am from and what drove me to start my own IT consulting business.

Thanks for your interest! I am convinced we will have a lot of fun together!

See you soon!