Featured Whitepapers
- Apples, Oranges, and Acorns - All Agile Development Tools Are Not the Same
- One's Enough for Agile Application Development Management
- Requirements Management 101 – 4 Basics Everyone Should Know
- Tips on Requirements Traceability – Learn How to Control Change and Improve Quality
- Scaling Continuous Integration to Large and Distributed Teams
Agile Methodologies - The Missing Path
Introduction:
In the past few years an increasing numbers of styles of software development models, referred to as agile methodologies have been gaining a lot of interest in the software development world. Promising an antidote to bureaucracy that old models were forcing, agile methodologies became very successful in gaining a huge number of followers and supporters all over the software landscape. Eventually the question changed from "Should we become agile?" to "Which agile methodology should we follow?" This article will try to answer this question by showing (in general) three of the main agile methodologies that have a long record of success. This article will also try to decide on the best way of implantation for these methodologies particularly in startup environments.
So let's start by going over the main concepts of the 3 chosen methodologies; Lean, Scrum, and Extreme Programming (XP).
KanbanTool: Worth Or Not Your Attention? (Review)
Kanban is a scheduling system and thanks to it you can easily monitor your team’s workflow. It tells you what should be done, when and by whom. In software development it is a board with a number of placeholders for work to be done. You and your team create separate tasks and place them on it. When the task is completed, you just relocate it to the “done” column.
Among the main advantages of Kanban boards are their simplicity and visualization of the working process. You and your team always know what others team’s members do just now without asking them about it.
A lot of teams use ordinary whiteboards with stickers as Kanban boards. It really works, but not in case of distributed teams, when members are located in different offices, cities or even countries. One more point against ordinary whiteboards, is that it is not convenient to use it when your team is more than 5 members, as you should have several boards to place all the tasks. Moreover, you should take a photo of the each status’s change of the tasks to analyze the team’s workflow.
What software development should NOT learn from manufacturing
In software engineering there have always been two schools of thought. One school feels that there is a lot to learn from manufacturing. The other school thinks that they are entirely different.
There have been 3 distinct phases in this debate:
- CMM Phase: Manufacturing has transitioned from craftsmanship to mass production – productivity and quality has improved many-fold. Software development can also benefit from such transition. CMM movement was born from this thought.
- Agile Phase: Manufacturing deals with machine, software development deals with people. Processes involving machines can be controlled precisely. People are inherently different and are not interchangeable. People communicate better face to face rather than through written documentation. From this realization agile movement was born.
- Lean Phase: Toyota revolutionized manufacturing through lean manufacturing system and dramatically improved quality and optimized cost. The core of lean manufacturing is empowered teams. Since agile movement also is based on self-organizing teams it must be possible to transplant the learning from lean manufacturing to software development. This lead to lean software development.
There is an apparent logic in all three reasoning. So, which advice should you follow? Are they compatible with each other? Before answering these questions you should look at the differences between manufacturing and software development.
Agile Marketplace - Announcements and Special Offers
The Business Case for ALM Transformation
Are legacy systems holding your company back? Breakthrough these technical constraints with an open and scalable environment that meets your unique business need to transform. There is no reason to be locked into an obsolete platform. The output of a number of recent transitions from legacy systems, this is practical white paper shares lessons learned and illustrates how guidance and enablement can pave the way for change.
Download this Whitepaper

