At the LAC conference, Agile seemed to be one of the hottest buzzwords and every company had its own success story in which they explained how much Agile methodologies have improved their business and the quality of the systems that they deliver.
The most popular Agile software development methodology nowadays is probably Scrum. All the companies that I visited in my job searching month, claimed that they have implemented it in their organisation. In fact, I haven't seen any company recently, that is intentionally not using Scrum or any other Agile software development methodology.
Although many companies claim to be Agile, I still have the impression that the quality of software systems and the ability to deliver software in time and within the budget haven't improved that much in general, although there are some exceptions, of course.
What is Agile?
I'm not an expert in Agile software development. One of the first things I wanted to discover is what "Agile" actually means. My feeling says that only a few people have an exact idea, especially non-native English speakers, such as people living in my country -- the Netherlands. To me, it looks like most of the developers with a Dutch mother tongue use this buzzword as if it's something as common as ordering a hamburger in a restaurant without consciously thinking about its meaning.
According to the Merriam Webster dictionary, Agile means:
1
: marked by ready ability to move with quick easy grace <an agile dancer>
2
: having a quick resourceful and adaptable character <an agile mind>
The above definition is a bit abstract, but contains a number of interesting keywords. To me it looks like if some person or object is Agile, then it has a combination of the following characteristics: quick, easy, resourceful, and adaptable.
Why do we want/need to be Agile in software development?
It's generally known that many software development projects partially or completely fail, because of many reasons, such as:
- The resulting system is not delivered in time or cannot be delivered at all.
- The resulting system does not do what the customer expects, a.k.a. mismatch of expectations. Apart from customers, this also happens internally in a development team -- developers may implement something totally different as a designer has intended.
- There is a significant lack of quality, such as in performance or security.
- The overall project costs (way) too much.
These issues are caused by many factors, such as:
- Wrong estimations. It is difficult (or sometimes impossible) to estimate how much time something will take to implement. For example, I have encountered a few cases in my past career in which something took double or even ten times the amount of time that was originally estimated.
- Unclarity. Sometimes a developer thinks he has a good understanding of what a particular feature should look like, but after implementing it, it turns out that many requirements were incorrectly interpreted (or sometimes even overlooked), requiring many revisions and extra development time.
- Interaction problems among team members. For example, one particular developer cannot complete his task because of a dependency on another developer's task which has not been completed yet. Also, there could be a mismatch of expectations among team members. For example, a missing feature that has been overlooked by one developer blocking another developer.
- Changing requirements/conditions. In highly competitive environments, it may be possible that a competitor implements missing features that a certain class of customers want making it impossible to sell your product. Another example could be Apple changing its submission requirements for the Apple Appstore making it impossible to distribute an application to iPhone/iPad users unless the new requirements have been met.
- Unpredictable incidents and problems. For example, a team member gets sick and is unavailable for a while. The weather conditions are so bad (e.g. lots of snowfall) that people can't make it to the office. A production server breaks down and needs to be replaced by a new instance forcing the organisation to invest money to buy a new one and time to get it configured.
- Lack of resources. There is not enough manpower to do the job. Specialized knowledge is missing. A server application requires much more system resources than expected, e.g. more RAM, more diskspace etc.
Ideally, in a software development project, these problems should be prevented. However, since this ideal is hard to achieve, it is also highly desirable to be able to respond to them as quickly as possible without too much effort, to prevent the corresponding problems to grow out of hand. That is why being Agile (e.g. quick, easy, resourceful, and adaptable) in software development is often not only wanted, but also necessary, in my opinion.
Agile manifesto
The "definition of Agile" has been "translated" to software development by a group of practitioners, into something that is known as the Agile manifesto. This manifesto states the following:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The Agile manifesto looks very interesting, but when I compare it to the definition of Agile provided by the Merriam Webster dictionary, I don't see any of its characterizing keywords (such as adaptable and easy) in the text at all, which looks quite funny to me. The only piece that has some kind of connection is Responding to change (that has a connection to adaptable), but that is pretty much everything I can see that it has in common.
Interpretation
This observation makes me wonder: How is the Agile manifesto going to help us to become more agile in software development and more importantly, how should we interpret it?
Because it states that the items on the left have more value than the items on the right, I have seen many people considering the right items not to be relevant at all. As a consequence, I have seen the following things happen in practice:
- Not thinking about a process. For example, in one of my past projects, it was common to create Git branches for all kinds of weirdly related tasks in an unstructured manner because that nicely integrated with the issue tracker system. Furthermore, merging was also done at unpredictable moments. As a consequence, it often came together with painful merge conflicts that were hard to resolve making the integration process tedious and much more time consuming than necessary.
- Not documenting anything at all. This is not about writing down every detail per se, but rather about documenting a system from a high level perspective to make the basics clear to everyone involved in a development process, such as a requirements document.
I have been involved in quite a few projects in which we just started implementing something without writing anything down at all and "trust" that it eventually gets right. So far, it always took us many more iterations than if most of the simple, basic details would be clear from the beginning. For example, some basic domain knowledge that may sound obvious, may turn out not be that obvious at all. - Not having an agreement with the customer. Some of the companies I worked for did integration with third party (e.g. customer's) systems. What, for example, if you are developing the front-end and some error occurs because of a bug in the customer's system? Who's going to get blamed? Typically, it's you unless you can prove otherwise. Moreover, unclear communication may also result in wrong expectations typically extending the development time.
- Not having a plan at all. Of course being flexible with regard to changes is good, but sometimes you also have to stick yourself to something, because it might completely alter the current project's objectives otherwise. A right balance must be found between these two, or you might end up in a situation like this. It also happened to me a few times when I was developing web sites as a teenager.
From my perspective, the Agile manifesto does not say that the emphasis should lie on the left items only. In fact, I think the right items are also still important. However, in situations where things are unclear or when pressure arises, then the item on the left should take precedence. I'm not sure if this is something the authors of the manifesto have intended to communicate though.
For example, while developing a certain aspect of a system, it would still make sense to me to write their corresponding requirements down so that everyone involved knows about it. However, writing every possible detail down often does not make sense because they are typically not known or subject to change anyway. In these kind of situations, it would be better to proceed working on an implementation, validate that with the stakeholders and refine the requirements later.
Same thing, for example, applies to customer collaboration (in my opinion). An agreement should be made, but of course, there are always unforeseen things that both parties did not know of. In such situations it is good to be flexible, but it should not come at any price.
Why agile?
What is exactly Agile about finding a right balance between these items? I think in ideal situations, having a formalized processed that exactly describes the processes, documentation that catches everything, a solid contract that does not have to be changed and a plan of which you know that works is the quickest and easiest path to get software implemented.
However, since unpredictable and unforeseen things always happen, these might get in your way and you have to be flexible. In such cases, you must be adaptable by giving the items on the left precedence. I don't see, however, what's resourceful about all of this. :-)
So is this manifesto covering enough to consider software development "Agile" if it is done properly? Not everybody agrees! For example, there is also the More Agile Manifesto that covers organisations, not teams. Kent Beck, one of the signatories of the Agile manifesto, wrote an evolved version. Zed Shaw considers it all to be nonsense and simply says that people should do programming and nothing should get in their way.
I'm not really a strong believer in anything. I want to focus myself on facts, rather than on an idealism.
Scrum
As I have explained earlier, nearly all the companies that I visited during my job searching month as well as my current employer have implemented (or claim to have implemented) Scrum in their organisation. According to the Scrum guide, Scrum is actually not a methodology, but rather a process framework.
In a process implementing Scrum, development is iterative and divided into so-called sprints (that take up to 2-4 weeks). At the end of each sprint an increment is delivered that is considered "done". Each sprint has the following activities:
- The Sprint planning is held at the beginning of each sprint in which the team discusses how and when to implement certain items from the product backlog.
- Daily scrum is a short meeting held at the beginning of every development day in which team members briefly discuss the progress made the day before, the work that needs to be done the next 24 hours and any potential problems.
- The Sprint review activity is held at the end of the sprint in which stakeholders review, reflect and demonstrate what is done. Furthermore, future goals are set during this meeting.
- Finally, the Sprint retrospective meeting is held in which team members discuss what can be improved with regards to people, relationships, process, and tools in future sprints.
In a Scrum process, two kinds of "lists" are used. The product back log contains a list of items that need to be implemented to complete the product. The sprint back log contains a list of items reflecting the work that needs to be done to deliver the increment.
Teams typically consist of 3-9 persons. Scrum only defines three kinds of team member roles, namely the product owner (responsible for maintaining the product back log and validating it), the Scrum master (who guards to process and takes away anything that blocks developers) and developers.
The Scrum guide makes no distinction between specific developer roles, because (ideally) every team member should be able to take over each other's work if needed. Moreover, teams are self-organizing meaning that it's up to the developers themselves (and nobody else) to decide who does what and how things are done.
Why agile?
I have encountered quite a few people saying "Hey, we're doing Scrum in our company, so we're Agile!", because they appear to have some sort of a process reflecting the above listed traits. This makes me wonder: How is Scrum going to help and what is so agile about it?
In my opinion, most of its aspects facilitate transparency (such as the four activities) to prevent that certain things to go wrong or that too much time is wasted because of misunderstandings. It also facilitates reflection with the purpose to adapt and optimize the development process in future sprints.
Since Scrum only loosely defines a process, the activities defined by it (sort of) make sense to me, but also deliberately leaves some things open. As I have mentioned earlier, a completely predictable process would be the quickest and easiest way to do software development, but since that ideal is hard to achieve because of unpredictable/unforeseen events, we need some flexibility too. We must find a balance and that is what Scrum is (sort of doing) by providing a framework that still gives an adopter some degree of freedom.
A few things that came into my mind with regards to a process implementation are:
- How to specify "items" on the product and sprint backlogs? Although the Scrum guide does not say anything on how to do this, I have seen many people using a so-called "user-story format" in which they describe items in a formalism like "As a <user role> I want to <do some activity / see something etc. >".
From my point of view, a user story (sort of) reflects a functional or non-functional requirement or a combination of both. However, it is typically only an abstract definition of something that might not cover all relevant details. Moreover, it can also be easily misinterpreted.
Some people have told me that writing more formal requirements (e.g. by adhering to a standard, such as the IEEE 830-1998 standard for software requirement specifications) is way too formal, too time consuming and "unagile".
IMHO, I think it really depends on the context. In some projects, the resulting product has only simple requirements (that do not even have to be met fully) and in others more difficult ones. In the latter case, I think it pays off to think about requirements more thoroughly, than having to revise to product many times. Of course, a right balance must be found between specifying and implementing.
- When is something considered "done"? I believe this is one of the biggest ongoing discussions within the Scrum community, because the Scrum guide intentionally leaves the meaning of this definition open to the implementer.
Some questions that I sometimes think about are: Should something be demonstrated to stakeholders? Should it also be tested thoroughly (e.g. all automated test cases must pass and the coverage should be acceptable)? Can we simply run a prototype on a development machine or does the increment have to be deployed to a production environment?
All these questions cannot be uniformly answered. If the sprint goal is a prototype then the meaning of this definition is probably different than a mission critical product. Furthermore, accomplishing all the corresponding tasks to consider something done might be more complicated than expected, e.g. software deployment is often a more difficult problem than people think. - How to effectively divide work among team members and how to compose teams? If for example, people have to work on a huge monolithic code base, then it is typically difficult to, for example, compose two teams working on it simultaneously because they might apply conflicting changes that slow things down and may break a system. This could also happen between individual team members. To counter this, modularization of a big codebase helps, but accomplishing this is all but trivial.
- According to the Scrum guide, each developer is considered equal, but how can we ensure that one developer is capable of taking over another developer's work? That person needs to have the right skills and domain specific knowledge. For the latter aspect it is also important to have something documented, I guess.
- How to respond to unpredictable events during a sprint? Should it be cancelled? Should the scope be altered?
In practice, I have not seen that many people consciously thinking about the implementation of certain aspects in a Scrum process at all. They are either too much concerned with the measurable aspects of a process, (e.g. is the burndown chart, that reflects the amount of work remaining, looking ok?), or the tools that are being used (e.g. should we add another user story?).
IMHO, Scrum solves and facilitates certain things that helps you to be Agile. But actually being Agile is a much broader and more difficult question to answer. Moreover, this question also needs to be continuously evaluated.
Conclusion
In this blog post, I have written about my experiences with Agile software development. I'm by no means an expert or a believer in any Agile methodology.
In my opinion, what being agile actually means and how to accomplish this is a difficult question to answer and must be continuously evaluated. There is no catch-all solution for being it.
References
I gained most of my inspiration for this blog post from my former colleague's (Rini van Solingen) video log named: "Groeten uit Delft" that covers many Scrum and Agile related topics. I used to work for the same research group (SERG) at Delft University of Technology.