Agile manifesto: something to remember

I like when people talk about Agile and different implementations. I like to listen to them, occasionally saying “Mhm”, “Yes”, “Of course”, when I am being presented with a bunch of papers with giant business plan, a year of initial implementation, at least year of development till the product can meet the market and get introduced to demanding client.

Where are we having the principle of people over processes here? Response to change? Software over documentation?

I think this is the time, for all of the agile-hunting lean lovers, to introduce the basic, very first, agile manifesto, on which all the frameworks (yes - these are only frameworks, someones ideas of how to make this four line into five hundred book based on which you will later on sell 600 USD ´worth´ certificates) are based. You have never heard it? Here it goes. I strongly recommend to learn it by heart:


Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan


If you feel like you want to have it tattooed on your chest, or at least agree strongly with this being the core, you can sign here the very original statement.

Now, Jim Highsmith says “We not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modelling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as "hackers" are ignorant of both the methodologies and the original definition of the term hacker.”. Completely agree. What is the key? Dynamics.

Constant observation of the market (benchmarking will be covered here a lot) and quick response are the key of agility. The customer will not likely change a lot in a couple of months, but what if a solution does? We have to be prepared with that.

I remember when launching eRural (one of the very badly planned relaunches with an important lack of financial planning and estimations by the way. Happens) we were constantly monitoring the core competition. We based some of the UI solutions on the conventions used on other sites, including this one. A week before official beta online, they changed all the layout. We were stunned. I decided then to maintain the same one, change some bits for better UX, and see how it goes. We were past deadline, devs were on the edge of their nerves, we did not have time for massive replanning on core design. The small changes we actually did were relatively simple, but still, we should have been a step ahead. We were not.

Lets now see the 12 points of Agile Software Development, and apply the principle of common sense to make it even clearer:

1. Customer satisfaction by rapid delivery of useful software → always deliver what gives your customer most perceivable value
   
2. Welcome changing requirements, even late in development → the response to change must be always possible, on every stage. The more usability tests on early stage of project, the better.
   
3. Working software is delivered frequently → If you work with SCRUM, try to deliver something great in each Sprint. Try to make weekly Sprints. May be difficult, but will be worth it.
   
4. Close, daily cooperation between business people and developers → Speak each others language, make everyone understand the business, not just the code. This is extremely important point in order for everyone to be able to understand why you prioritize certain deliverables.
   
5. Projects are built around motivated individuals, who should be trusted → Aaah, the trust. Something we might have an issue with. What may help here is on what are you going to base the trust. Everyone in the company should be trusted, because being there should be always one of the best places they can be for relatively objective reasons: growth possibilities, opportunities within the company, flexibility, salary… etc. Shall the trust be based on that? Would you retain top talent in a place with low salary and bad conditions? Why would they be there while having a possibility of being anywhere else? Everyone thinks about their own best. Try to make this the principle of trust, and deliver them the best.
   
6. Face-to-face conversation is the best form of communication (co-location) → If possible, always go face-to-face. If not possible, everything that is possibly closest to that (Skype, Hangouts, etc.)
   
7. Working software is the principal measure of progress → Make it working software instead of documentation. Use it. Test it. Reuse it. Try to sell it on early stage to see what the customer really wants. Just make the stuff work and be out there as soon as possible.
   
8. Sustainable development, able to maintain a constant pace → The team should get used to the pace of work. If you rush too much, the burnout is inevitable. If some weeks are much tougher than others, the inconsistency may translate into fear (why do we have to rush? is there anything we should be worry about?) and fear in the team is never a good thing. Make people feel comfortable and safe. Maintain constant pace.
   
9. Continuous attention to technical excellence and good design → I don't think this principle need any explanation. You need your product to be understood, and you need it free of bugs. Absolutely basic and incredibly important.
   
10. Simplicity—the art of maximizing the amount of work not done—is essential → Make everything as simple as possible, but not simpler. Always. We come back to the point of: if people don't understand the product, they are not going to buy it. The concrete value proposition.
    
11. Self-organizing teams → Interactions, and interactions, and interactions again. Make the team organize itself. Let them pass the tasks to each other, manage the Kanban board as preferable, solve the problems that may make the team not deliver on time. Being a manager is  like being a host on a party. Prepare everything, make sure everyone is comfortable, but never force things (important point is the change of leadership style according to level of team maturity, I will cover it shortly). 
12. Regular adaptation to changing circumstance → In business, everything changes quickly, and to survive, you have to adapt. Being able to see the trends and catch the cores in terms of profitability vs sustainability is what we want to focus on in the process of market change. Lets make it a weekly meetings first. Lets then see how it goes.