November 5, 2020, 8:30 a.m. to 6 p.m. EDT | November 6, 2020 – February 7, 2021, On-Demand | Online Conference
Please login or join to subscribe to this thread
I am fascinated by the history of business management and culture, specifically the interaction / learning between software and non-IT organizations in the age of Lean and Agile. We know the Manifesto for Agile Software Development was written for software, as you say, but it was built on decades of lessons from other domains as well as existing software development frameworks. Now those same lessons are applied beyond software development and both continue to evolve. It will be interesting to see what changes are in store over the next 5-10 years.
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
If you were to take a poll, I would wager that you would find more people have received actual training on Scrum or other agile approaches than have received actual training on traditional approaches. Most of the people I've worked with on traditional projects, over the past 16 years, have all had slightly, or grossly, different opinions on how a waterfall project should be run. Once I started coaching my teams on how a given project would be run, my projects started getting more successful. This coaching came after careful consideration of the correct approach for the project.
I often sidestep the semantics of agile by noting that project managers (and others) typically have two aspirations.
-- The first is to be fast (or faster than before).
-- The second is to be flexible.
Generally, it is more difficult to promote flexibility, especially when the project's product involves something tangible. Software is generally more amenable to techniques that allow for fast and flexible work. Tangible products often have a nature that make it difficult to reprioritize, or change commitments, or reverse.
I'd encourage readers to look at the product (software versus tangibles) and you'll see that the various techniques are more suitable for one or the other.
Please login or join to reply