Gotta Go Fast

[In which the fourth lesson swiftly teaches you all about Agile]

Maria Aprillia Devira
UKM Heroes
6 min readOct 17, 2019

--

One day, a group of 17 people thought,

“We’re all doing these different approaches to developing software. We ought to get together and see where there are commonalities in what we’re thinking about.”

this somehow resulted in a meeting at a ski resort in Snowbird, Utah in 2001. They got together, did some skiing first for some reason and then discussed about their different approaches in software development and their commonalities, if any. There were a lot of things they didn’t agree on, but the ones they did became the Manifesto for Agile Software Development.

Agile Software Development?

Image by Luis Goncalves

So what exactly is Agile Software Development? It is an umbrella term for a set of frameworks and practices based on the values and principles that are expressed in the Manifesto and the 12 Principles behind it. Unlike other approaches to software development, Agile focuses on the people doing the work and how they do the work together. Collaboration and the self-organizing team is a big focus in the Agile software development community. So what are the Manifesto and 12 principles?

The Manifesto

There are four values in the Agile Manifesto. In their words, while we value the items on the right, we value the items on the left more.

Individuals and interactions over processes and tools. This value puts people on a higher pedestal than processes and tools. If instead the processes and tools are the one that drives the development, people would be less likely responsive to customer needs and changes. An example of this would be communication, where if it focuses on individuals it would happen anytime anyone needs anything, while if it focuses on process it would be systematic and scheduled which would usually only focuses on certain topics.

Working software over comprehensive documentation. Although documentations are important, this values stresses that sending out working software to the hands of a customer would be more important than documents. By getting working software out to the public faster, they could get feedback from real users faster and change their software to the customers needs faster. While sending working software is more important, focusing on the creation of documents is not a bad thing…as long as you don’t go overboard with it.

Customer collaboration over contract negotiation. This highlights the fact that while contracts are often used in businesses, it should not replace the need to actually contact the customer about their needs or challenges. The close collaboration with real users ensures that we can deliver effective and useful solutions to the customers. The feedback building during development would also effectively reduce risks.

Responding to change over following a plan. This value doesn’t exactly abolish all plans during the development process, but rather it creates a space for change and allow developers to stray from the plan to respond to any changes caused by customer feedbacks. As such this allows the team to adjust its priorities and plans whenever it would make strategic sense. This would benefit the team because they would not be stuck with an outdated plan.

The 12 Principles

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. The best way to make any customers happy while delivering valuable software is to send out early, frequently and listen to the market continuously. Here instead of releasing a final product, you release an iteration of the product while continuously make improvement on it based on customer reviews.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Change is always the constant in the world, here we support the observing of the changing customer needs and competition and changing plans when necessary.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Here we break the product into small iterations and send them out frequently which lets you validate the current progress of the product.
  4. Business people and developers must work together daily throughout the project. Communication is an important component in agile and regular communication between developers and business people would create trust and a successful product which gained insight from both sides.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. More motivation means better and more work done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. This encourages both sides to communicate in real life about the product and progress.
  7. Working software is the primary measure of progress. The ultimate success is a working product that customers can love.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Keeping up with demanding frequent release can be tough, this idea is to keep morale high and promote good work-life balance to prevent a collapse in the team.
  9. Continuous attention to technical excellence and good design enhances agility. Whatever you role is, you would want to make sure that at each iteration your product is improving. Create an excellent design now rather than coming back later to fix it.
  10. Simplicity is essential. If you want to quickly send out product, you would want to cut out the unnecessary complexities. Keeping things simple is the best way for constant and frequent progress.
  11. The best architectures, requirements, and designs emerge from self-organizing teams. A team that is organized and works together would be more likely to create the best designs compared to a team that is disorganized and goes solo.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Continuous improvement also extend to the team and not just the product. With a reflection, the team can figure out what they needed to improve to keep the product going.

Our Practice of Agile

Scrum by source

In our group project, we use the scrum methodology. Thus, our group consists of the Product Owner, Scrum Master and the Dev Team.

Our process of scrum starts with Sprint Planning, followed by Daily Meetings and ends with Sprint Review topped off with a Sprint Retrospective. This can be repeated as many times according to the amount of sprint we have. During Sprint Planning we bust out the Scrum Board and choose which Product Backlog Item we would like to do. This is not a very fast process due to difficulty of choosing tasks that would fit our busy schedule. The real time communication with our Scrum Master help us decide our current tasks and after alls done, we transfer the contents of our Scrum Board into trello for portable access. Every Wednesday and Friday after the Sprint Planning and during the duration of spring we hold our Daily Meetings. There we, again, bust out our Scrum Board and discuss our finished to-dos and take on new tasks. Although I promised to bring food or snacks during Daily Meetings to keep up the morale, unfortunately my wallet could not keep up so we opted on buying food with our own money. After the sprint duration is over, we hold a Sprint Review where we show the Product Owner what we have done during the sprint, then they can reject or accept the product. Last, but definitely not least, we hold a Sprint Retrospective after the Sprint Review in which we discuss the positives and negatives that we felt during the duration of the sprint and try to fix the negatives to become a better team through it.

With that lengthly paragraph out of the way, our implementing scrum as our methodology has kept us well motivated and although there are some principles we could not adhere to due to out status as a college student, we believe we are quite active and motivated to do our work well as best as we could.

Well that’s it and that’s all, see y’all next time and remember, you gotta go fast!

Sanic de Higheg

--

--