Project management is a complicated business. There are endless methodologies, software options, team member roles, and changing expectations, not only within companies or industries, but across the project management field as a whole.
There is hardly a supposed process improvement that is not critically examined by the project management community. Whether it is about what should define agile project managers or Scrum Masters or which project management software is best suited for companies: hardly ever do everyone agree.
Despite all this, there is a trend that has been growing steadily since 2015 – if not longer: Agile project management is becoming more and more important. And not without reason: it is particularly well suited to software development, for example.
With all the discussions about issues such as adapting agile methods or Scrum vs. Kanban, it is easy to lose sight of what agile software development really is – and how it works.
Agile software development
That's why we want to take the time today to examine exactly what Agile actually is and how you can use it to advance your software development.
This guide to agile management is about how the method came about, what development cycles look like, what significance agile development has and what advantages and disadvantages it offers. If you are not interested in the history of agile methods and want to find out straight away how agile processes work, just skip the first part.
The Complete Guide to Agile Software Development
The History of Agile
The Institute of Electrical and Electronics Engineers has traced rudimentary agile project management methods back to Los Angeles in 1957. At that time, Bernie Dimsdale, John von Neumann, Herb Jacobs and Gerald Weinberg worked closely together to develop software for IBM and Motorola. Craig Larman quotes Weinberg in his article “ Iterative and Incremental Developments. A Brief History ” (we translated the quote from English):
"As far back as I can remember, all of us felt that the waterfall model was unsuitable for very large projects, or at least misunderstood reality. The waterfall description enabled us to do something else: to recognize that we were doing something different, something that did not yet have a name of its own other than 'software development.'"
The waterfall model was the predominant form of project management at the time. It is closely related to Gantt charts and shows what needs to be done at which point in a project in order for it to move forward.
This method made software development incredibly complicated. The waterfall model is based on predictability and sequencing. Software developers need a more flexible project management method that makes room for all the errors, bugs, setbacks and independence that are typical of the software industry.
It was not until the 1970s that more formal Agile approaches emerged, led by Dr. Ernest Edmonds , Tom Gilb , and the Systems Development Center of the New York Telephone Company. The ideas did not fall on fertile ground. In fact, when Dr. Edmonds presented his ideas to the Journal of Computer Aided Design , they were rejected out of hand. The only comment the journal sent back to Edmonds was, "If you don't know what you're going to do before you start, you shouldn't start!" Edmonds then took his work to General Systems , where it was finally accepted .
In the 1990s, software developers were at their wits' end. The new programmers were mainly from Generation X (born between 1961 and 1983) and were used to independence as "latchkey kids". At the same time, they had not quite left their rebellious teenage years behind when they started working and brought this attitude with them into the office. Craig Larman found that developers found the waterfall model to be " over-regulated, regimented and extremely controlling ". It just wasn't right for them anymore.
In the 1990s, many straightforward and versatile project management methods found their way into software development, including the Dynamic Systems Development Method (DSDM), XP , Scrum and Feature-Driven Development (FDD). Even though all of these systems predate the Agile Manifesto, they are now considered part of the Agile methodology.
The Agile Manifesto
From February 11 to 13, 2001, 17 people met at The Lodge at Snowbird Ski Resort who had three things in common: a love of good food, a love of skiing, and a desire for an alternative to documentation-based, cumbersome software development processes . To this day, they still refer to themselves, without irony, as "organizational anarchists." At this meeting, all participants signed the Manifesto for Agile Software Development , which is based on four concepts:
“Individuals and interactions are more important than processes and tools.
Working software is more important than comprehensive documentation.
Cooperation with the customer takes precedence over contract negotiations.
Responding to change is more important than following a plan.”
Co-founder Jim Highsmith writes about the history of the Agile Manifesto (original in English):
"To succeed in the new economy and to move aggressively in the era of e-business, e-commerce and the Internet, companies must free themselves from arcane policies and employment for employment's sake. This freedom from the trivialities of the corporate world is what attracts proponents of agile methods and is frightening to traditionalists. Frankly, agile approaches scare corporate bureaucrats - at least those who like to drive processes for their own sake rather than trying to do the best for "the customer" and deliver something tangible "as promised" in a timely manner when they have nowhere to hide.
The agile movement is not anti-method. On the contrary, many of us want to restore credibility to the word "methods," to restore a balance. We advocate models, but not creating diagrams that then simply disappear into dusty corporate archives. We advocate documentation, but not hundreds of pages that are never maintained and rarely used. We plan, but we recognize the limitations of planning in a turbulent environment. Anyone who calls proponents of XP, Scrum, or other agile methods "hackers" has neither understood the methods nor the original meaning of the term "hacker."
The Agile Manifesto emphasizes that none of the authors believe in a magic formula. This makes it all the more difficult to define what Agile actually means: The founders do not believe that they know all the answers, nor that there is one method that is equally perfect for every development team. Their approach is inevitably very liberal. As they themselves have emphasized often enough, they are concerned with helping others and not with making rules. They want to support others with agile methods and at the same time learn from them themselves.
Perhaps it is precisely this approach that makes their system so successful and has led to its adoption.
Agile is gaining popularity
From 2001 onwards, the number of project management processes resulting from agile methods increased rapidly. After a short time, the Agile Alliance and Scrum Alliance were formed and in 2001 the classic Agile Software Development with Scrum was published. Certified Scrum courses became as ubiquitous in the world of project managers as terms such as "Scrum Master" and "self-organization". In 2007, IBM wrote:
"Agility is everywhere. Ignoring it means getting lost in today's technical discourse. Gaining knowledge about it will help you make informed decisions about whether it's right for you. It will also give you an understanding of many other emerging practices and methodologies. If you're in technology management - no matter what level - it's not just your responsibility, it's a requirement for your survival."
Today, 10 years later, agile methods in their numerous forms are used almost as standard in software development.
Agile software development
“Agile project management” is a collective term that encompasses a wide variety of methods in software development alone. These include:
Adaptive Software Development (ASD)
Crystal
Dynamic Systems Development Method (DSDM)
Extreme Programming (XP)
Feature Driven Development (FDD)
Kanban (depending on the type of use)
Lean
Scrum
Although these are different software development methodologies, in this article we will only focus on what connects them when it comes to Agile. This section is organized according to the four main beliefs of the Agile Manifesto.
1. Individuals and interactions are more important than processes and tools
No matter how you look at it, it is people who develop software, not computer programs or cogs in the machine of a company.
Don't get me wrong: Agile project management software is a great resource for project managers. This type of project management software offers tools to improve communication, track bugs, and plan software releases. But software alone cannot replace a good team. VersionOne explains :
"We should interact with each other, collaborate, work out details, agree on things, ask questions, have lunch together, get to know each other better and build trust and bonds. It's about face-to-face interaction. In the new agile world we live in, we need to be more social than in the past to produce software. And that's not going to change. Anyone who chose IT in the hope of not having to deal with people may now have a problem. Yes, we all still need times when we can have our peace and quiet and concentrate. There are certain areas designed for focused work. Most companies know how important this is and offer small areas outside of team rooms. They also give employees laptops or tablets instead of desktop PCs. This mobility makes it easier to just go somewhere else when needed for privacy. Ironically, it also offers better opportunities for collaboration."
In other words, the folks at Snowbird wanted to design a method for developing software, but they wanted to make it more team-focused. They put that first and foremost, and for good reason. The idea is that teams that don't work together are inevitably slower to adapt to setbacks and have a harder time developing high-quality, marketable software.
Agile teams that prioritize this value, however, ideally benefit from various advantages:
Communication between team members is fast, clear and efficient.
There is a close bond between team members, which enables effective teamwork.
All processes are flexible enough to adapt to new events and changing circumstances.
The team members feel responsible for their respective project areas and free to design them.
All team members are encouraged to innovate and take risks.
2. Working software is more important than comprehensive documentation
In large companies, government agencies or even teams with overzealous managers, it quickly happens that half days are devoted to documentation.
How many times have you prepared a long expense report, waited for approval from management or the board to move on with a task, or simply worked hard for a client? Doesn't that sound pretty tiring at some point and a rather poor kuwait telegram data prerequisite for innovation?
Unfortunately, this is the case – and proponents of agile methods want to remove this obstacle.
Agile teams strive to keep documentation effort as low as possible. Every document should support product development – and nothing else.
Instead of wasting hours trying to capture everything that has been done and will be done, agile teams focus on the actual product . They don't approach the product as a whole, but focus on functionality.
For example, imagine a house.
In traditional methods, construction managers would use construction management software to evaluate how far the project is progressing. For example, if the foundation is laid, the shell is up, and siding, insulation, and wiring are complete, the new home would be about 65% complete. However, this home is not yet habitable: the work on the home is 65% done, but you currently have zero completed homes.
In agile software development, "65% complete" means that the entire project is 65% complete. In software, this means that the most important parts of the software are finished. Done. Completed. Ready to go. If something isn't ready, the team should rework it in iterations until it's complete.
Agile teams that emphasize these values ideally benefit from a variety of advantages: