What do the following countries: China, Egypt, England, Italy, Portugal, and Spain, just to mention a few, have in common? At some point in the past they were superpowers and for some reason or another they let someone else take their place.
If I would have been living in Italy, specifically in Rome 2000 years ago, I would have told the emperor and their citizens that we had to change our ways or we would allow a country to collapse. That is easy said because we have learned about the history of Rome and the many other countries that went through the same experience, yet it has always been a somewhat different situation.
I would assume that in any of the countries that have been through the rise and fall that some citizens realized the problem but their voices were hot heard or probably were suppressed by their peers and governments. I am not a politician so I am not well versed on the possible avenues that would be available for one to follow to wake up the country and avoid the fall.
In real life I am a software engineer that enjoys reading and experimenting in order to keep on learning and improving.
Are you familiar with Agile development? Of course you are. Chances are that you are also a practitioner. I am in the same boat. Have worked on different companies that use some form of Agile.
Now let’s jump a few decades back when a group of software developers got together to see if they could change things at work. At the time software developers were being pushed to spend more than 40 hours a week writing and testing code to meet some capricious deadlines that did not have well defined requirements nor approach to get them done.
The main issue with the 40+ hours was due to the fact that the software for one reason or another, mostly due to requirement and priority changes, took a long time to develop. When requirements changed the software had to follow. Given a fixed schedule, the only possible way to get the code released on time was to work 40+ hours. That was the reason that motivated the following group of seventeen software developers to propose a unified change:
o Jon Kern
The Agile Manifesto is quite simple and brief. It was published in February 2001.
“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”.
Apparently the team also put together a set of twelve principles of Agile Software.
-
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
-
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
-
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
-
- Business people and developers must work together daily throughout the project.
-
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
-
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
-
- Working software is the primary measure of progress.
-
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
-
- Continuous attention to technical excellence and good design enhances agility.
-
- Simplicity – the art of maximizing the amount of work not done – is essential.
-
- The best architectures, requirements, and designs emerge from self-organizing teams.
-
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
My comments from the value section follow:
-
- Listening and adapting should be above procedures and tools. This idea is great yet how often do you see it followed?
- A project needs simple and up to date documentation. It facilitates working software and reduces the number of issues/bugs considerably.
- How often in a project (unless it is very simple and requires no more than a handful software developers) does the team deal with the customer. The answer seems to be that your customer is management, not the product expert.
- Blindly following a plan is absurd due to the fact that changes do come up. That said, following changes might lead to not finishing the project at all.
My comments from the principles section follow:
-
- I have worked on a few projects that I interacted with the customer. In most projects the customer is not the end user. How often does software need to be delivered? I like for all team members to release each and every Friday afternoon by the end of the workday. The software should include more or better features than the previous release. The software should be put in the hands of the customer and the customer must make use of it.
- Changing requirements need to be managed. They cannot change everyday because nothing would ever be built or tested.
- Once a week to make sure that each modification can be implemented in a fixed period of time and the customer can experiment with the software and provide feedback on their findings. One liners in email messages should suffice.
- Not sure what this means. I prefer to work with the customer which is the same as the product expert. This is important to get valid and useful feedback.
- This comes from the general attitude that was prevalent at the time the manifesto was generated. In general management was not versed in software development. The idea was to generate a lot of documentation so requirements (that change) were cast in concrete and the design and tests would follow them. Projects at the time seemed to take a few years on average at a time when hardware and software was changing monthly.
- This one is a goodie. Humans need to interact and discuss things to make sure all is going to plan. Lack of communication is an indication that things are not going well. The best approach is to have short, correct, and simple documentation which is reviewed and updated as needed before implementation and testing. Very early in my professional career I encountered the KISS (Keep It Short and Simple) rule. I have since followed it.
- Software needs to be tested as much as reasonably possible before incorporating it into a candidate for release. It seems that in the majority of projects, changes are submitted lacking the necessary tests. That causes problems as soon as the code goes into production and the associated urgent patches are needed. In addition we have the backlog which is a way to list the problems/bugs that went unnoticed during the release process and were not addressed by patches.
- This is an idealistic and utopic state of mind. I have never encountered a team that would meet such expectations.
- Nice but any and all engineering disciplines need to pay attention to detail so their products are solid and lasting. It seems that with software products are there to be patched (as bad as once per week) otherwise they would not last more than a few months.
- To me simplicity has a completely different definition. That said, reducing the amount of code is something that should always be welcomed by all teams. A software product will not crash when a bug is encountered in non-existing code!
- Not sure about this one either. Architecture and mechanisms to follow it is not as common in software development. That said, discussing approaches and following them through is the best way to engineer software.
- This is self improvement and in my opinion should be brought up when a flaw in the way something is being done appears. This gets back to iterating with team members and making sure there is simple and accurate documentation to follow.
I would suggest reading books on the Agile subject. Preferably if it is a mix of old and new ones. Always pay attention to what is going on in your Agile project and verify if there are better ways to proceed. Doing things that way they are done without proper explanation is not good at all.
You might have noticed that the names of the seventeen signatories of the Agile Manifesto are links. I spent time reading about them to better understand what motivated them to generate it.
Based on my findings I decided to search for the first copy of the Scrum documentation that was generated by Ken Schwaber and Jeff Sutherland. I was not able to find it, probably given that it was generated for OOPSLA 1995.
Tried contacting Ken Schwaber in different ways and ended up using Twitter. If I receive a response I will update this post with my findings.
In the 1980’s I worked at a Fortune 500 company. My boss at the time, an electrical engineer, was responsible for the custom hardware and associated software for a big project. I was the software lead for one of the devices.
Sometime after the project was completed we both moved on to start our own businesses. One morning, out of the blue, he called and asked if I was interested in doing lunch. The building where my office was located had a decent cafeteria that served breakfast and lunch, so we decided to have lunch at 11:00 AM (and yes, for some odd reason we used to have lunch early in the morning).
When he walked into my office, he showed me the cover of a magazine featuring among others an article in Extreme Programming. His words were “I guess you were into something” referring to the Cyclic Development Process (CDP) methodology that I had developed a few years back. Extreme Programming was developed by Kent Beck who is one of the signatories of the Agile Manifesto.
On a completely different note, Andrew Hunt and Dave Thomas (also a signatory of the Agile Manifesto) wrote the book The Pragmatic Programmer. I got a copy and read it. That was around 1999. A month or so ago I purchased the 20th Anniversary Edition of The Pragmatic Programmer. I was going to read it next, but a couple other books caught my attention (Data Oriented Programming and Getting Started with Natural Language Processing) and decided to read them first. Later this year I will read the new edition of the Pragmatic Programmer and will let you know my thoughts in this blog.
Remember that one of the best ways to learn is to read and experiment. If your organization is using Agile then you just need to collect data to understand if improvements could be made. If so, make sure you contact your management. Remember that Rome at some point collapsed!
John