rss

What is Agility?

In a broader organizational context, being Agile is the extent and the speed to which an organization is able to interact. In an ideal situation, the optimal corrective action would be calculated in real time. The set point would be instantly derived from the vision, strategy and goals of the organization.

The model below makes it comprehensible that there are a lot of factors to take in account when changing an organization. It also shows how internal and external behavior influence each other.

The reality is also that many unpredictable, illogical and irrational human decisions influence the system. Emotional or counterproductive behavior can not be neglected but is also very difficult to take in account.

How Scrum can go wrong

Most of the popular online discussions about implementing Scrum lack a holistic understanding. The questions are usually limited by how a small group of people within the organization can be more Agile. Very quickly, such a transformation ends unsuccessfully leaving frustrated programmers behind.

Frequently, the present state of the organization is not very well understood. Unjustified conclusions are often the result of rushed and superficial analysis. Ultimately, the outcome is a costly battle about the terminology and rituals to be used for the same way of working and result.

Examples

The first part of this story may seem rather abstract. For that, I will try to illustrate it with some (fictional) practical situations:

• Example 1: Web agency with 15 employees

  This company faces the problem that customers often complain about a lack of clarity about the process and insufficient quality of the produced websites. After many internal discussions some developers suggest that Scrum might be a solution. They quickly follow a Scrum training and declare Scrum as their new way of working.

  But serious problems arise right away. The clients of the web agency demand clear guarantees about the product to deliver. They also feel very uncomfortable with the fact that they have to be so involved. The clients avoid taking any responsibility and refuse to appoint somebody for the role of Product Owner. The Scrum team assigns someone within the team as a substitute.

  The sales team has a strong benefit to get new clients by promising everything that they want to hear. The new work approach makes it even easier. The already problematic scope creep becomes a bigger problem which results in more bugs and functionality not meeting expectations.

  The owner of the web agency had understood that Scrum would make everything much more profitable. But the lack of signed documents resulted in clients who do not want to pay without that certain work is performed first.

  There are also a lot of internal problems. Some employees are very demotivated because they can not work alone anymore. The whole well-intentioned attempt is getting out of control and causes a lot of of trouble.

  Analysis

  The internal structure and regulations are drastically changed. But vision, strategy and goals are not adapted to the new situation. They are actually under stress and paralyzed by unknown implications.

  No account has been taken with heavy financial consequences. For sales, the incentive model does not fit the new way of working: they have to choose between being honest or having personal gain.

  The environment sees the services as a commodity product and doesn't accept to invest in it like a research project. The market is full of similar providers with readymade products for a fixed price. Internal procurement rules prohibit to take such risks.

  Assessment

  Trying to solve a problem of no clear work process by choosing Scrum is troublesome because Scrum is not a process. The focus of it is much more on innovation. It often solves the problem of heavy bureaucratized organizations where there is no freedom to try new things. This web agency had a problem with standardization of their product and process. While Agile practices could be helpful, a much more thorough transition was needed to succeed.

  The quality problems could have various causes such as not the right skills of the developers. Limiting and clarifying of the scope of the project has much more to do with sales training and positioning of the company than the internal structure. 

• Example 2: IT department of a large corporation

  The department has understaffing and the requests are piling up. The waiting times are very high and there are many complaints. Technology has changed a lot in recent years, but knowledge gathering and education of the employees stood still because of the high workload.

  The products do not meet the expectations of the internal organization and therefore people often use 3rd party products and even products of competitors.

  The motivation of the developers is very low because salaries have not increased in proportion to the salaries of the sales department.

  External consultants are brought in to analyze the situation and recommend a solution. After some interviews and exploring the work flows, they come up with a report that describes a mix of Kanban and Scrum to implement.

  But after the first two months, the complaints have only increased and waiting times have become longer. The board has a incidental function: it is perfect to show that they can do one thing at a time. The new definition of Done justifies when more time is spent on a task. Agreed release schedule according to 2 weeks sprints ensures that there are no ad hoc releases and therefore lot of customers walk away.

  Analysis

  The new work approach does not change anything concerning the motivation of the individual developers. They are even more demotivated because the Kanban board shows the impossible amount of work that the team needs to accomplish with insufficient capacity.

  Human resource management plays a key role, but the plans didn't involve attracting new employees and increasing the capacity.

  Technology progress is ignored. Dumping of legacy software would be a huge time saver.

  Assessment

  Choosing a more Agile approach for the development team is misplaced. A proper portfolio analysis would bring faster results. By eliminating maintaining low profitable software, capacity would be released for higher priority work.

  An education plan and acquiring new people for missing knowledge areas would be a quick fix.

Searching for a Magical Process®

There is not an universal formula or a Magical Process®. Every situation has other contingency factors. Dynamic and complex relations in an organization should be taken into account. Having good intentions and following the latest trend is not necessarily a formula for success.

All creators and supporters of development methods, claim that their method does deliver better software, with less effort and faster then other approaches. While such an idea is nice and calming, part of your brains want proof and why it is so. Software development process is not a religion and therefore there is no place for faith fanatics. (Although I must admit that most online discussions on the topic suggests otherwise.)

The popularity (or notoriety) of Agile methods are growing and a quick Google Trends query suggests that it's not on its peak.

However, there is one major dilemma. As much of a fan of empirical data with rigorous statistical validity, it is maybe impossible to scientifically prove that one methodology is any better or worse than any other. Software engineering doesn't have (yet) uniform scientific data to compare and back up touted methodologies such as Scrum or Agile. Projects depend on domain, knowledge and skills of the people involved, process methodology, the choices made at various phases of the project from the technology to use to the system architecture and design: It becomes very difficult to look at projects and generalize information in such a way that it is both scientifically valid and useful across the majority of projects.

Besides, the "No true Scotsman" fallacy is overused and is very easy to apply on this subject. It's comparing apples to oranges where everyone can easily say: that is not a real apple and this not an orange neither!

A sufficient definition of the development methods are needed to be able to compare and say something meaningful about them.

This is completely sad when we consider the whole Waterfall method is a straw man issue and that Royce didn't described or intended to follow such a method in his paper.

In general, maybe we can say that it's pretty much impossible to draw any meaningful real-world scientific conclusions because every (non-trivial) software project is unique and software development is, by its very nature, non-deterministic. But this is a fundamental and an even greater statement than we started and is crying for a foundation.

But there are definitely attempts to compare efficiency and effectiveness of software development methods. The book "Making Software: What Really Works, and Why We Believe It" does include some chapters treating the subject. But (regrettably) there is not a sentence stating that Agile methods make a significant difference. There are plenty of anecdotes that suggest that using a specific method in a specific situation has led to great success. But these kind of subjective validation is dangerous and does not in itself prove a causal link.

There are also serious allegations that promoting software development methods is just one big money-making exercise for a group of consultants. Certification has created a small army of consultants and trainers who are constantly busy training and coaching a bigger army of certified Scrum practitioners.

At the other hand, there is nothing wrong with getting some help. Even it is not a thoroughly scientific method, some anecdotal best practices can point in the right direction and can be a push in the back even it is all a bunch of common sense.

Emphasizing the practices of minimizing unnecessary overheads (excessive planning and documentation) while concentrating on incremental delivery of client-specified functions can't be too wrong.

If it is difficult to plan ahead, adopting mechanisms for “empirical process control” that focus on feedback loops sounds alright too. Blind and unthinking practitioners or commercial interests do not alter this conclusion.

In the end, "you get what you measure". Agile is popular, sounds cool, you can't get blamed, it gives some best practices, emphasis on motivation and responsibility. But we must also be honest and acknowledge that it is not based on real evidence that it is better and that agile is maybe a too hollow / empty concept. When there is a great product owner, then Scrum for example can be certainly faster than a waterfall approach with a bad specification document. But a bad product owner can be certainly slower than waterfall with a great specification.

In Rapid Development: Taming Wild Software Schedules, Steve McConnell identifies a number of factors to consider when choosing a lifecycle methodology:
⁃ level of understanding of the requirements
⁃ level of understanding of the architecture
⁃ desired reliability, risk management
⁃ schedule constraints
⁃ amount of process overhead
⁃ mid-project "course corrections"
⁃ ability to provide the customer with visibility
⁃ ability to provide management with visibility
⁃ sophistication of the development team and management

Maybe Agile is just a fad of IT that happens and there will be a new one that gets people excited. Just trying to improve the efficiency of software development is what we all want. Doesn't really matter how it is labeled. I will therefore end this nuanced as a research paper: I hope that this blog post will alert empirical researchers to the possibility that their studies will contribute to the understanding of software development processes.

Links

• Making Software: What Really Works, and Why We Believe It - http://www.amazon.com/Making-Software-Really-Works-Believe/dp/0596808321
• The Best-Kept Management Secret On The Planet: Agile - http://www.forbes.com/sites/stevedenning/2012/04/09/the-best-kept-manage...
• Scientific evaluation of programming methodologies - http://programmers.stackexchange.com/questions/131578/scientific-evaluat...
• Should there be more scientific study of the effectiveness of various hyped-up ideas in software development? - http://programmers.stackexchange.com/questions/140173/should-there-be-mo...
• Are there any studies on the Efficiency/Effectiveness of Agile vs Waterfall - http://programmers.stackexchange.com/questions/125429/are-there-any-stud...
• Why I'm done with Scrum - http://news.ycombinator.com/item?id=4510943
• Managing the development of large software systems Dr. Winston W. Royce - http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
• Why Scrum Won - http://java.dzone.com/articles/why-scrum-won
• Agile: Where's the evidence? - http://allankelly.blogspot.nl/2012/03/agile-where-evidence.html
• Agility in the avionics software world - http://www.agile-itea.org/public/papers/agileavionics.pdf

1. Raw Video file storage is not easy

Storing large volumes of video needs careful planning and strategy. You need to keep in mind that scaling form Terabytes to Petabytes and beyond is going to happen. Video file sizes are increasing constantly (couple of years a go, 320 pixel video's with a low bit rate where totally acceptable and now 1080p streaming video is the expected quality) while the need for different file formats (browsers and mobile devices support distinct formats like MP4, WebM etc.) These files need to be redundant and there needs to be a back up plan if some things go wrong.

2.VIdeo quality is subjective

What is better 1080p or 720P video? The essential and often forgotten question is: which bit rate, what are the quantization parameters and other technical stuff such as GOP size or i-Frames? The difference of 720p and 1080p video at same settings is almost impossible to perceive if you watch it on a 50" TV.  Besides these technical difficulties, there is an other factor: The expectations and perception of video quality is rising every day because once the audience watched a certain quality, they refuse to experience less. In short, the term high quality or 1080p video does not say much about both the generated or the perceived quality.

3. Concurrency estimation of streaming video is really hard

Prediction is very difficult, especially about the future said Niels Bohr. This is even more true if it is about video. Forecasting how much people are going to watch your video stream (for example an event) is even in a very broad range is almost impossible. What if 10 people are starting to watch but something happens and they Tweet  about it. Suddenly there are hundreds of people watching it and snowball effect brings thousands of viewers. Reserving extra capacity on its own not a problem but if it tends to infinity, it's not something that you can do for yourself as a hobby without excessive costs.

4. There is a lot of competition in the video hosting vertical

There are around 30 companies that are trying to compete in this niche. Everyone tries to find the right market product fit by aligning, branding, focusing, differentiating on specific aspects. The industry is maturing and this is a really good thing. I also think that this competition is a good thing. It forces to be creative, it stimulates faster pace of innovation. Above all, it proves that there is a large enough market.

5. Video is not suitable for everything

if you have a hammer everything looks like a nail is especially true for video. While it is tempting to use it everywhere, sometimes there are just more appropriate formats for content. There are currently a lot of start ups that are trying to be the Instagram for video. I don't know if this is going to work because looking at photos and liking them is a whole other experience than having to watch video's. It is more time consuming to watch, it has a different usage moment and so on. At the other hand, some content is specifically suitable for video. I think in the coming years, we will see really creative implementations where we previously had not thought of.

6. The difference between a free video hosting like Youtube and a professional video hosting is still unknown

If you are not paying for it, you are the product being sold. This is absolutely not necessarily a bad thing if you consciously choose for it and know the consequences. Sites like Youtube are great (I use them personally every day) and it is even better because they are completely free. But they have a special purpose and terms to use. If you are for example a video producer and you don't want to share the rights (Youtube explicitly states that you retain all of your ownership rights however,  you grant YouTube a very broad license too) and sometimes that can be a problem. Things like arrangements concerning service and quality can also be an issue. There are also a lot of technical limitations that sites like Youtube do not facilitate because they are not intended for it.

The paradoxical psychological phenomenon is that when the price is a factor, suddenly people will think different about this issue. If you have a coupon in your hand with something like "Build Your Own Pizza: Any pizza, any size, any toppings for fixed €10". Then there is an urge to get the maximum out of it in stead of ordering a really good pizza. This also applies to the quantity: according to some research, individual taste ratings of pizza tended to be inversely related to how much is consumed.

Same thing happens with web development. The problems with ordering a pizza will be limited because most people have experience with eating a pizza and are able to conceptualize the consequences. Most clients don't have a lot of experience with web development and are unable to foresee the effects of their choices and will insist to add as much features as possible. At the same time, they will have a nice feeling during the development because they negotiated the maximum out of it.

Maximizing the amount of features of an application is the same thing as adding as much toppings to your pizza or sugar to your coffee as possible. It will not make it tastier. A good cook knows the exact balance of ingredients to make something really delicious and he doesn't do that by adding as much as possible of each.

Spray & pray

Finding a unique market and product combination is the next level of the challenge. Developing only a excellent product is not enough. There must be a perfect match between the product and the demand for it. Sometimes it is possible to detect an unfulfilled need and design a product to accommodate the necessity. It can also be possible to launch a product and it generates a need.

There is not a universal formula to generate an ingenious product idea. It can be luck, precise analysis or serendipity to come up with it.

Finding the right product/market combination can be compared to finding that annoying mosquito in the middle of the night. If you have really little amount of insecticide spray, the chances that you will kill it will be reduced by the number of rooms that you spray in your house. Following the sound and smacking it on his head is much more effective and has the least amount of disadvantages.

Doing random things without any boundaries is the least probable method to be successful. As a client of a web development project adding as much as possible random features is a sure way to get a unsuccessful product. Each choice is a trade off. By adding 2 features instead of 1, you didn't negotiated 1 extra feature for free. You actually negotiated that 1 feature will get half as good as it might be possible. By diluting each feature, you need to pray more that you did the right trade off. By focusing to a tight scope, it is much easier to adjust and transform your product to find the right combination because there are less variables.

More to read

If you don't believe me or want a more scientific explanation from a computer science perspective, you can read Donald Knuth about "If you optimize everything, you will always be unhappy." From management point of view what I actually tried to explain is lean manufacturing in a funny an accessible way. You can also watch really cool video's about lean manufacturing. It is also useful to read the philosophy of Deming to understand where it all comes from.