Why I feel natural with Agile principles

I have been working in an Agile environment for some years, and I have always felt at my ease. Why? In a short, because the 12 Agile principles are ‘common sense’ to me, I feel well and easy to understand and apply them.

Let’s take them one by one.

1) Satisfying the customer

1) “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

At the beginning of the 2000’s, when I was student, I got insights about ‘User Experience‘. If today everyone agrees on its relevance, it was totally different at this time. Considering “people first”, “user-centered” approach (design, UCD), “users are always right” were not so common and even hard to evangelize, especially within an IT environment dominated by hardware and software performance. Mindset was more: “if software is powerful, it succeeds”.

It took time, but IT managers have since acknowledged this is wrong. Digital products are successful if users use them and are satisfied by using them. Users or customers, we are on the same line. So yes, I strongly agree that satisfying user / customer is the highest priority.

Still about this first principle, providing continuous feedback, and even more delivery of valuable “solution” (e.g. software) makes customers satisfied. Because you get involved, you create a link, you build a relationship with them. And digital marketers will confirm that customer are looking more for a link, a connection that makes sense, rather than a perfect product. If you provide the best product but nothing more, customers will leave you. But they will remain loyal if you inform them on a regular basis, no matter how fantastic is your product.

 

2) Embracing change

2) “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Because I am a (IT) “generalist” profile, curious and continuous learner, change is part of my nature. When framed correctly, by putting the right (mental) “filter” on it and maintaining transparency for all involved people, change brings value.

This is because I have always been considering users and customers as first priority. I got this mindset during my studies in IT when attending lessons in Human-Computer Interaction domain. Usability and User Experience fields are not so far, and all three share the same “User-centered” (or “Customer-centric“) approach.

To sum up, providing satisfaction to customers must remain priority one. Consequently, there is no excuse to resist change, when change serves customer interest.

 

3) Delivering frequently

3) “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

Era of immediacy, “zapping generation”, built-in obsolescence (but it may not last because obsolescence will become obsolete): because of these factors, customers are highly demanding for new things, upgrade, added-value, diversity, change. Consequently, the best way to bring them satisfaction is to deliver something new, different, based on their preferences, on a regular basis. And in order to know their preferences or which new feature or even which subtle improvement they will appreciate, we need to get their feedback early and constantly.

I do think this, because every time I hear: “Will my customers be satisfied? Will this product be successful? We have to be sure this is the right thing, this is what they want”, I often say: “Ask people! Ask them. You cannot be sure, you cannot think for them. So first meet them, talk to them, show what you have already done, so you get a 100% sure feedback and then you can keep developing your product.”

And then, no need to wait too much time to repeat this ‘loop’. Depending on the complexity of your project, after a couple of days / weeks / months, keep engaging users / customers by asking again for their feedback.

In case you do not have any new feature to introduce? That is no excuse: ask for feedback anyway because in the meantime people may have changed their mind and they want something different. So again, instead of implementing something you are really proud of, but that would be absolutely useless for your clients, save time and money by working on what they are expecting.

 

4) Business and technical people working together

4) “Business people and developers must work together daily throughout the project.”

Who knows at the best what has to be done? Business. Who can do the job? Developers. So why keep them separated? Strong collaboration with transparent communication and multiple interactions are core elements to a successful organization.

 

5) Providing first trust and good environment, then getting work of quality

5) “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Granting trust a priori is a bet. Many organizations are reluctant to take it: first individuals has to guarantee their reliability, with satisfying outcomes and behaviors. And then, they can benefit from trust of their organization. But it takes time. Why not granting trust at the very beginning and see what happens then?

Provide satisfying work conditions, trust, and make people empowered, self-organized, responsible for their tasks, proactive. Then you get the best of your collaborators, as soon as they have started working with you.

 

 

6) Fostering face-to-face rather than remote or asynchronous conversations

6) “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Nothing can replace efficiency and effectiveness of human interactions, when they occur in a liveable context. Because voice, gestures, overall attitude that only intuition perceives and all these kinds of details, that digital communication cannot perfectly render, take part of discussion and information exchange.

The best teams have in common to share information with efficiency. The reasons are that team members:

• know each other very well
• have a lot of face-to-face conversations
• share more than work
• feel they are part of a consolidated team
• are willing to help each other. In some cases, they help more a ‘mate’ (or a friend) than a colleague

 

7) No metrics or KPIs are better than working software

7) “Working software is the primary measure of progress.”

What business people prefer getting when they ask for project status? Is it a complex Excel sheet with tons of KPI? Or a demo of working features they have requested for? If you answer “both”, that’s ok, but set the priority to ‘working software’ anyway.

 

8) Regularity, sustainability, performance

8) “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

“a constant pace indefinitely” means regularity in the delivery. Regularity means balance between comfort and pressure: too much comfort makes people demotivated, and too much pressure makes them stressed and after a while, they will give up. Because optimal performance is a genuine mix of comfort and pressure:

By delivering new piece of working software on a regular basis, it offers predictability to customers, and usually this is one of the elements they are the most satisfied with.

 

9) Do not underestimating skills and design

9) “Continuous attention to technical excellence and good design enhances agility.”

Once again, this sounds common sense, but having the right skills and good design ensures the Dev Team can deliver on time, and repeating this at a maintainable pace. Moreover, the team can improve the product and deal with change. On the contrary, lack of skills will add confusion, generate frustration, decrease self-confidence for some individuals and finally reduce productivity.

 

10) Simple but functional

10) “Simplicity – the art of maximizing the amount of work not done – is essential.”

Trying to build the perfect product is a waste of time and resources. I know this is common sense, however many projects in many companies still tend to this approach. The main reason is that Delivery or Product Managers fear their clients will be disappointed or reject their product because something is missing or because it does not look like a fully polished software, website or device.

But way of consumption is changing, and now people 1) are ok with changing often their stuff (and paying the price for it) and 2) they require for new features in short periods of time. To sum up, the mindset of being patient to get a solid, everlasting or timeless product, and to keep it during years, is over now.

Most startup companies build their success thanks to a Minimum Viable Product. You guess a MVP is far from being ‘finished’, but if people like it, they pay for it and know that new and optimized versions will be released soon.

So, stay focused, implement and deliver the ‘satisfying minimum’. Let clients using (and enjoying) a functional version, and work on the next version to keep them fervent. This is why we say “less is more“.

Source: http://techstory.in/minimum-viable-product/

 

11) Making a team self-organized to get better results

11) “The best architectures, requirements, and designs emerge from self-organizing teams.”

Implicitly, a self-organizing team is composed by team members who have skills, motivation and decision-making power. The outcome is that they take ownership, communicate and help with each other, share ideas, look for improvements and so deliver quality products.

 

12) Self-improvement

12) “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

One core element in Agile is getting regular feedback from the Product Owner (and Business people) and adjusting work if necessary (“iterative feedback”).
What about doing the same within the Scrum Team? It sounds natural (once again I write this, but this is the purpose of this post) to ask for and to give transparent and pertinent feedback (constructive criticism) in order to work more efficiently. Benefits will go to the team (as a group) and to each member (as individual).