Let’s say you have a business case in a monolith software system which is already in its maintenance phase. The software is however viable and valuable for the company. The implementation a business case is spread throughout the code in a numerous domain objects, services etc. Where exactly does one document it? Basically we have two options – either not document the business case or write a code comment in some entry point class/service or ideally a controller (if it’s a MVC). If we decide not to document, we rely on the fact that every developer that needs to make change to the business code will conscientiously go through the code, understands exactlty how it works and after that implements the change. If we choose to document in the code, we need to update the comment every time the business case changes. Of course, there is also a third option which is – document the case along with the change externaly in a task management system. Both the second and the third option would somewhat contradict the agile value and the principle as they state that the working software is more important and the face-to-face conversation should take precedence over documenting.
In my real-life example there is a mixed state between the three above mentioned scenarios with the result that no business case is sufficiently documented and the whole business knowledge is kept safe by maybe 2 developers and one project/product manager, both long-time employees.
This leads to the following problems. Every change that needs to be made to this system (and changes are rare because the system is in its maintenance phase) is accompanied with the risk of breaking multiple business cases. (monolith system!). With missing regression tests or generally very few tests, the stability of the system is in danger every time a change is made. If the persons who have the knowledge about the busieness cases are not available (not in the office or worse – no more in the company), no change can be implemented relialbly.
Fortunately there is one agile principle that works as a safety net for all other principles:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
If the self-organizing team is really motivated to get the job done they will make good use of the safety net. The question what happens if they are not leads me to the next problems I have with the agile development process. Who will keep the team motivated? Who should make the decision which person belongs to a team and who has the responsibility for not choosing the right person. How is the effectiveness measured?
The agile principles and values are part of a manifesto. As such they are positively formulated and they assume the best about the people involved. They assume that every developer will act in the name of his team’s best interest. And he/she probably will. According to his/her understanding, which is most probably subjective. As long as we don’t measure the team effectiveness objectively we can’t tell if it has become more effective. What the agile process lack in my opinion is time and cost management as a way to measure effectiveness. This would imply some sort of project management and this is something that agile manifesto doesn’t mention at all.
There are trends and fashions. Trends and fashions are statistical categories. When you say to me that something is trending, I understand that a lot of people are using it/doing it. The existence of a trend doesn’t say anything about the meaningfulness of its subject to me. Some of the people following the trend has a solid understanding of the subject. Some are just cheerleading. Some are genuinely excited. Some are comfortable with the status quo and are just tagging along, generally not opposing the fashion, thus passively enabling its further growth. Some are abusing the subject of the trend, either unwillingly or knowingly, for their own purposes. Eventually the latter are giving the subject a very bad name. I would like to write a word or two about the latter. My idea is to show with examples from my own experience what the abusing or misusing of the agile principles can lead to in a company, that follows the agile way whitout using a strict set of rules for its projects. Or in the immportal (I would leave the typo as it is for apparent reasons) words of Captian Hector Barbossa, these are „more what you’d call guidelines than actual rules“.
For the last couple of weeks I’ve been looking for a new job and I’ve hardly seen an ad that doesn’t mention agile. „We are agile company“, „we live the agile process“, „we are looking for agile developers“, „you will be working in an agile team“, „as part of our dynamic agile developer’s team“ are some of the most common clichés used in the descriptions. It seems that in the HR world, the term agile stands for freedom or some coolness. But freedom from what? From the oppression of the non-developers? From the deadlines and the time constraints? What makes the term agile so cool?
My first encounter with the agile development methods was in the university in a lecture about software engineering. I can still remember what the professor said back then – the agile developing methods are best suited for innovative projects with a lot of unknown factors; basically projects where one is not able to make a reliable time estimation for a requirement or a set of requirements. As a sidenote to his main statement, he mentioned with a bit of a smirk, that one would better apply the agile principles every time one notices that the end user/client can’t say exactly what he needs. Which kind of makes sense. An that is exactly what one of the principles of the agile development states
„Business people and developers must work together daily throughout the project.“
The idea is basically that you try to incorporate the people with the requirements in hand in your developing process thus avoiding the danger of implementing something they didn’t ask for. We all remember the old comic strip – what the developer sees, what the user wants, what the marketing people sell etc. you know how it goes. I guess this principle was a reaction to the traditional way of developing applications, where business people gather and write a specifiaction document a few hundred pages long and pass it to the development along with a deadline which is as the saying goes, defined as „yesterday“, because it’s almost never possible to meet. It seems that the principle solves couple of problems very neatly by simply bringing all people having stakes in the project together and let them exchange in a friendly manner. On one side, you restore balance by allowing the developers to get out from the basement and say to the business people what they really think about their unreal deadlines and requirements specification. On the other, you allow the business people to tell the developers that their idea of a product can’t be sold to anybody who isn’t a developer/nerd, a hardcore fan of Star Wars / Star Trek or a person who isn’t happy about a product that only works on some developer’s machine.
As a CEO of the company you should be extremely happy to have straightened those sort of things out as early in the project as possible. But here comes the tricky part – as a CEO of the company or any executive who is responsible for the project you should know what kind of people do you have in your product team. And what’s more important – what kind of roles are they having and what responsibilities each one of them is having. In a waterfall world the results and deadlines are extremely well defined in terms of time and scope. Product team works together with the end user for two months and delivers a requirement specification document. Then, the developers team work for one year and delivers a running application. After them come the testers. In an agile world you don’t have a principle about time, scopes and roles. The only principle that mentions time to market is:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
So basically you state that you want to be as fast as possible. But how? Who takes care about time in an agile team? If it lies only in the hands of the developers they would enjoy their freedom for as longs as they are able to. No deadlines. Finally they are free from the oppression of the business people. It sounds right. After all one of the values of the agile methods is:
Individuals and interactions over processes and tools
Real-life example – as a CEO you have an idea for a product. You don’t know how good. But you want to see it live. Your company is modern and „lives“ the agile process. You have a small problem – you don’t have a product team. You don’t have people who refine and validate your idea. Basically you are the only business people. But you don’t have time for a lengthy requirements specification sessions. And also, you are costly. But you are also agile. So what you do is, you gather your developers and give your best at explaining what your idea is and either let them roam freely or you give them a deadline. You don’t have project management, because the agile principles don’t mention time management. Also:
The best architectures, requirements, and designs emerge from self-organizing teams.
A fact of life – no developer likes time estimations, because who wants to put pressure on himself. Since your self-roganizing team consists only of developers they all agree that they won’t do time estimations. They will instead focus on the quality of the product as they understand it. Let’s assume that they are all clean code hardcore fans and they will clean that code until they drop. According to most definitions yours are some fine developers. But after a month (or whenever you have the time to take a look at the progress) of cleaning that code, you realize that that’s not what you’ve had in mind, inspite of following the agile principles.
What happened? The CEO has left the whole process in the hands of the developers and they’ve delivered (at best) a running prototype of his idea which he is not satisfied with. He has burnt a month of developer’s time and didn’t let product people refine his idea, check if it’s useful/feasible. He didn’t appoint anyone to control time in his team and let them decide only on code quality. The developers are grumpy and unsatisifed as well, because the thing they’ve implemented will never go live and most probably they will have to start from scratch. According to most of the principles the company’s process was agile. Freedom is not so good after all.
In a wonderful post about the role of executives in a company Avery Pennarun wrote the following:
To paraphrase the book, the job of an executive is: to define and enforce culture and values for their whole organization, and to ratify good decisions.
Not to decide. Not to break ties. Not to set strategy. Not to be the expert on every, or any topic. Just to sit in the room while the right people make good decisions in alignment with their values. And if they do, to endorse it. And if they don’t, to send them back to try again.
Avery Pennarun * the original quote comes from the book High Output Management by Andy Grove
Further down in his post he explains why that should be this way:
If the executive makes their own decisions and forces them downstream: the executive doesn’t have enough information to make good decisions in detail, so the decision won’t be optimal.
In my real-life example the CEO was the sole business person in the agile team. To be fair the scenario would’ve probably worked out OK in the end if this was his only project, his only team and he didn’t have anything else to do but to look after this one project and this one team. The only thing he should have done is to slip into mutliple roles – project manager/scrum master, product developer and perhaps also a lead developer. Such a scenario is probably very typical for the early stages of a startup company. This would also explain to certain extent the popularity of the agile process among startup comapnies. And it does make sense. If I was an executive of a startup, the last thing I would’ve wanted was to spend maybe 6 months at refining and specifying my product on paper before I start with the actual development. It appears that the agile process becomes a trap for companies after they pass the initial stage and start to grow. This is when the executives should let go.
Баня, построена по времето на Адолф Хитлер и в съответствие с национал-социалистическите предписания. Неокласизицизъм, колони, фонтанчета. По времето на войната е разрушена, а след това – реставрирана. В момента е общинска собственост, демек държавна. Освен басейн, в банята има сауна. Пардон, сауни – всяка с различни температури, аромати и т.н. На покрива – открито простраснство с шезлонги и басейн с ледена вода, да може хората да се охлаждат и да зяпат звездите. Предполагам и покривното пространство е държавно. За звездите не знам.
Седя си аз в 92-градусовата сауна и се грея. В един момент, помещението започва да се пълни с хора, така че не остава свободно място. Всичко се заема за отрицателно време. Недоволствам малко наум, щото хиляда пъти отваряха вратата, всички градуси избягаха навън. И на всичкото отгоре няма ведро. По-сухо е само в Сахара и на Северния полюс. В този момент влиза сауна-майстера с ведро, черпак и мокра хавлиена кърпа. Разгеле. Човекът поздравява с Grüß Gott! и обявява церемониално „Aufguss.“ Сипва два черпака, оставя ведрото и започва да се разжожда из сауната и да раздухва топлото с кърпата. Всички умираме от кеф. След няколко тигела, чичото се връща в изходна позиция и сипва още 1-2 черпака. Оставя ведрото, пак хваща кърпата и подхваща маршрута. Раздухва качествено. Всички умираме от кеф и вече леко от жега. Процедурата се повтаря още веднъж, след което майстера си събира инструментите и пожелава приятна вечер. А какво правим ние? Аплодираме. Звучно.
Въпросът ми е – каква е причината този държавен служител да проявява такава инициатива и да показва такива умения?
Заглавието звучи малко драматично и пресилено, признавам, но това е само, за да привлече внимание. Ето, честен съм.
Както повечето хора, живяли по времето на големите хитова на Queen и аз бях много шокиран, когато по телевизията казаха, че Фреди е умрял. Нямам спомен да съм бил много шокиран от болестта толкова, колкото от това, че няма да има повече такава музика. Явно съм смятал, че без него, нищо повече не може да се получи. Както повечето хора и аз бях запознат основно с „големите“ хитове – Бохемската рапсодия, You’re My Best Friend, We Will Rock You, We Are the Champions, Don’t Stop Me Now. Впрочем, не съм сигурен, че родителите ни си даваха сметка за строфата
I am a sex machine ready to reload Like an atom bomb about to Oh oh oh oh oh explode
но всички бяхме фенове. Дълго време вкъщи имахме само една плоча – Greatest Hits и тя се радваше на внимание от всички членове на семейството без значение от тяхната възраст. MTV в България се появи малко, след като групата вече не съществуваше и клиповете дадоха на хитовете още малко детайли, колкото да затвърдим, че Queen нямат аналог и са наистина на високо ниво. След Innuendo, който много ме впечатли, макар че беше депресиращ и по тази причина не ставаше за слушане всеки ден, лека полека и аз загубих интерес. От време на време се връщах, за да преслушам любимата селекция и толкова.
Когато дойде Интернет, обаче, мнението ми за Queen се промени на почти 180 градуса. Това лошо технологично явление, което обвиняват за почти всички съвременни злини, разруши до голяма степен митът Queen за мен. Сега ви виждам, как доволно потривате ръце и си казвате „Хаха, тоя благодарение на Интернет е разбрал, че Фреди е обратен и се е разочаровал.“ Хаха, не. Първо, аз това си го знаех и преди и изобщо не ми пречеше и второ, хехе, не се оставям такива неща да ми влияят на музикалните разбирания. Случи се това, че за първи път получих неограничен, безплатен и нелегален достъп до албумите на групата от ранните 70 години, направо казано първите два, които са с тотално невпечатляващите имена – Queen и Queen II. Тогава разбрах, че Queen не свършва през 91-ва година, ами още през 74-та. След него започва нещо, което поетът е описал така:
Just take a look at the menu We give you rock a la carte We’ll breakfast at Tiffany’s We’ll sing to you in Japanese We’re only here to entertain you
и завършва с Innuendo, където отново правят опит да са искрени. През целия този период са ни продавали по перфектен начин rock a la carte, без да им мигне окото. A Night at The Opera – можем кабаре и опера, ще пуснем най-дългата къса опера по радиото и тя ще стане хит. A Day at The Races – ще пеем на японски. News of The World – ние сме шампиони. Jazz – а дали не бихте искали нещо като фюжън и естествено най-великия melancholy blues на света? The Game – Елвис е жив и яяя, какъв уникален фънк бас на Джон Дийкън! Flash Gordon – що да не направим една рок опера. Hot Space – e, добре де, диското не ни се получи, но беше забавно, нали? The Works – хващаме поп вълната. A Kind of Magic – сърфираме и всички ни гледат. The Miracle – няма по-добри сърфисти от нас.