DEV Community

First_name Last_name
First_name Last_name

Posted on

Agile Manifesto in examples

If you have been working for many years, you might have a question: "Why was project not successful?".
You might say: "My team followed all the processes and used modern technologies and tools. We had comprehensive documentation. We did everything according to the contract. We followed the plan. All deadlines were met. What did we miss? What did we do wrong?"

I won’t answer these questions, I’d rather tell you five short stories.

Story One:

I was hired for my first job as a tester after a 5-minute interview.

The first question my future boss asked me was:
– How do you feel about people who swear?
– I find it terrible! – I answered.
– Then we cannot work together. Almost all the men work for me, they constantly swear.
– I disagree, if I work here, they will stop.
– OK. When can you start?

On my last day in this company I was told that he had never regretted his decision.

Story Two:

Several years ago I worked as a teacher of the “Software testing” course.
All the questions from my students I separated into two big groups.

One group:

  • Should I learn any programming language to receive a job offer for the QA Engineer position?
  • Who gets more money: Manual or Automation QA Engineer?
  • Which rating should I have to achieve a “success” badge in my “Software Testing course” certificate?
  • Is it possible to become a software developer if I am working on the software tester position now? Do developers have a higher salary?

And another group:

  • How to select some value in the dropdown in my UI auto test?
  • When is it required to add detailed steps for test cases?
  • Are there any tools that simplify generating test data?

Statistically those who asked most of the questions from the 1st group didn’t pass interviews. Unlike those who asked questions from the 2nd group, they are QA Engineers now.

Story Three:

I used to use the following tools and programming languages in the daily work:

  • XSLT – a language for transforming XML to HTML
  • SVN – a version control system
  • MS Project – a project management software
  • Weebly – a website builder
  • IIS – a web server software created by Microsoft
  • WatiN, Test Complete – tools for UI auto testing
  • NUnit – a unit testing framework

I don’t need them anymore.

Story Four:

One of the most complex applications I’ve ever tested is Sitecore CMS.
At the beginning the CMS was developed by five friends who had an idea. They worked close to each other, nobody thought about the requirements documentation.

Additionally we had a strong rule: “Do not disturb developers”.
So, no requirements, no ability to ask questions to developers, no access to the code. Sometimes when we (testers) didn’t understand something in the CMS work we used to decompile DLL files with the .NET Reflector and read the code to understand implementation of the feature. If it made sense we did our testing. If not we asked to re-work the feature.

Of course, this story sounds crazy but we improved our way of work.

That time we didn’t have proper processes and comprehensive documentation but we created a product that is popular nowadays (even after 20 years).

Story Five:

We were developing an application that allowed customers to book hotel rooms and tickets for different events.

It was New Year eve, when we started another sprint, and agreed on a set of features with the client. But then he changed his mind, and requested to add the possibility for discounts and gifts (according to the rules that he proposed).

Thanks to this idea, which we of course implemented, the client received additional profit, and we received bonuses for our work.

I won’t tell you a story when several strong specialists lost a client because they didn’t have proper collaboration with each other and didn’t listen to client’s feedback.

Or a story when a big set of regression tests, gaps in the automation and lack of time might lead to death (comprehensive documentation didn’t save us from this mistake).

I would rather say “thank you” to:

  • wise managers who hire those with potential
  • interviewers who don’t ask me very detailed questions about the tools I used (because tools become deprecated but experience is always in trend)
  • colleagues who love their work and inspire me
  • clients who provide a feedback (because their feedback is more important than contracts and plans)

Agile Manifesto saying:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Fully agree ☺

Our projects are like children. They are more successful when they are simply loved. Sometimes they can be successful even in spite of what we are doing for their own good. And they will never be happy if they were used to please our pride.

Top comments (0)