The best approach to project management is a widely debated topic. Today, we’re diving into the key components of the Lean and Agile philosophies, Scrum, the Kanban methodology, the Waterfall practice, and the DevOps approach. The underlying point of this exercise is to extrapolate the differences, and illustrate the merits of each.
Agile
- Individual interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Scrum
- Rugby-like approach to Agile that started in application development seeped into unrelated professions of every type.
- Divides chunks of time into “sprints” that include planning meetings, demos, daily stand up, a retrospective meeting, and potentially several backlog refinement sessions.
- The ScrumMaster or “coach” works on removing any impediments the team may encounter during a sprint.
Lean
- Think of value from the end user or customer standpoints.
- Identify steps that create value, and eliminate work unconnected to value where necessary.
- Adhere to the flow -- tight sequence of value-delivery in the customer experience.
- Allow and encourage customers to “step ahead” in the sequence to discover value-adds.
- Revisit and repeat the process in a constant fashion.
Kanban
- Visualization method for prioritizing workflow and fostering a high-level understanding of workloads.
- Kanban boards show real-time priorities and tasks to limit operational waste, discourage multitasking, and improving flow of completion.
- Tasks and projects understood as stories that make clear to stakeholders the objectives, pathways, and goals—keeping leadership in the loop and less likely to interrupt work.
DevOps
- Combines the processes of the Agile model with the Lean principle’s continuous flow of value.
- Development and operations come into contact with each other; both teams may spend time in customer-facing roles.
- Characterized by small, incremental updates and frequent deployments.
Waterfall Model
- Classic linear approach that dates back to the early days of mainframe computing.
- Starts by drafting requirements onto a master document.
- Requirements are analyzed and modeled.
- Models and analyses figure into designing an architecture.
- The architecture provides a sketch that code and integration implements.
- The implementation undergoes a verification process before launch.
- The product undergoes constant maintenance once introduced to the customer.
We see how the “state of mind” of a team is driving each process. That is the common thread here, and therein lies the biggest challenge. It's difficult to get a group of individuals to adopt a uniform way of thinking.
Each process suffers its own pitfalls
Agile suffers in large organizations. The more stakeholders a project has, the more formal processes need to be. When more people are involved, the greater the chances that not all are versed enough in Agile to execute it properly. Reactionary decisions have negative repercussions in this setting. Agile can succeed in the enterprise when applied to smaller parts of a larger objective.
The Scrum variant provokes the opposite complaints. Developer micromanagement during the sprint is a pain point. Friction between IT and technical creatives can arise without the necessary soft skills to drive the project. The framework tends to be meeting-heavy, which presents challenges in and of itself.
Lean doesn't succeed because of poor implementation over 90 percent of the time. Lean works—but not as a Band-Aid. Misguided directives lack creativity; management often attempts to slap “lean” processes on top of a foundation unaligned with the rules. Lean seems simple, but actually requires a complete shift in mindset which managers are not often prepared to lead.
Over 80 percent of failed software projects used the Waterfall methodology. Personnel have a hard time adapting to changes in direction, which in a programming context, involves backtracking and re-documenting everything. Costs skyrocket and work slows when this occurs on a large scale project leading to its demise. Use Waterfall on smaller, simpler projects for a better effect.
Kanban doesn’t succeed 75 percent by experts who equate it to a fad diet—maintaining the process is too intense to attain over time. Since it is a relatively new approach, managers might not have the expertise and wherewithal to maintain the board. Some engineers do not appreciate abolishing outright multitasking on the job; other times teams become confused by the storyboard workflow and it mutates into something ineffective and not-Kanban.
Final thoughts & takeaways
Real talk. There is no universal best way to tackle a project or run a team. Putting forth that narrative overlooks the purpose of this discussion. Success lies in implementation, not the philosophy itself. If an Agile project ultimately winds up a disaster, a failure to properly execute tenets is a likely culprit. Not that this makes the process any less frustrating. What is your approach? Share your thoughts on our
LinkedIn page.
