... and there you have the official definition of Agile(1).
Similar: nimble, lithe, spry, supple, limber, sprightly, dexterous, deft, willowy, graceful, light-footed, fleet-footed, active, lively, quick-moving, nippy, twinkle-toed, fleet, lightsome, alert, sharp, acute, clever, shrewd, astute, on the ball
Opposite: clumsy, stiff, slow, dull
... and in the software world,
"relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans."
Welcome back.
I recently came upon a online article on Scenario-Focused Engineering: Take an Experimental Approach which has an interested snippet on Agile. Copy-Pasted below verbatim.
Agile was born from the software developer community in response to the need to build higher-quality software with less wasted effort in an environment in which precise customer requirements change over time and are hard to articulate upfront(1). Agile was invented independently by software engineers, but fascinatingly, it aimed to solve a lot of the same root problems that user-centered design aimed to tackle.
If you’re working on an Agile team, a lot of this chapter probably feels familiar. You already loop quickly in sprints, likely somewhere from one to four weeks in length. It’s easy to squint and see how one loop around the Fast Feedback Cycle could map to an Agile sprint, complete with a customer touch point at the end to get direct customer feedback on the increment you just delivered. It’s likely that some of the same activities we discussed already occur during the course of your sprints.
Scenario-Focused Engineering differs from Agile in two main areas, which we believe help fill in some missing gaps. First, we believe that it’s not necessary for every sprint to deliver shippable code(2). In early sprints, it’s often more efficient to get customer feedback on a sketch, mockup, or prototype before investing in production code. However, we completely agree that getting customer feedback at the end of every sprint is absolutely essential, whether that sprint built prototypes or production code.
Second, we believe that the product owner is actually a mythical creature. We challenge the idea that any one person on the team, no matter how senior, no matter how often they talk with customers, can accurately channel exactly what real customers need and desire and provide accurate “customer” feedback at the end of a sprint. Agile oversimplified the whole business of understanding customers by giving that job to one person—the product owner(2). Anything beyond the most basic customer needs are too complex for that approach to work reliably in today’s market. We hope you’ll find that the ideas in this book give you practical ways to break out of that mold and actually talk to real customers(3).
Interestingly, most Agilists have concluded that shorter sprints work better than longer ones: sprints of one to two weeks are better than sprints of three to four weeks. We have come to a similar conclusion; you should probably aim to finish a single cycle within two weeks(3). Left to their own devices, most teams will spend too long on an iteration. Time boxing is key to keep people moving, and Agile sprints are a really natural way to time box on a software project.
Here are a couple of things that I agree and disagree in the above paragraphs,
Agree -
- move quickly & easily - that is the crux of Agile. If Agile does not allow a team to be nimble and dextrous then it is not helping. This certainly does not mean individual team members are themselves fast which is a common misconception that most sr. leaders have. The movement is never within a sprint. It is always at the boundary of a sprint.
- It is really not necessary for a team to deliver shippable code every sprint. This is another common misconception that most sr. leaders and especially product managers have that if you are not shipping code at the end of the sprint then you are not delivering anything worthwhile and hence have not done ANY work. Software development is a thought process even the 'Build' stage of the Fast Feedback Cycle, can be broken into 'Design', 'Development', 'Test', 'QA', 'Deploy', etc. which is a much longer and involved process.
- Two weeks is the sweet spot for a sprint. I've worked with teams have have 4 week sprints and also with teams that have 1 week sprints. In neither of them did I see an improvement in meeting sprint goals. In many organizations, this is usually left to the team and I completely support that. Some teams work well in 4 week sprints and some in 1 week sprints. At the end of the day, is the team delivering an incremental change in the product.
Disagree -
- If customer requirements are hard to articulate upfront, to me, that means the customer does not know what they really want. If a customer knows exactly what they want, it should be much easier to articulate it and convert it into a technical requirement specification. Is anyone ever going to tell a customer, 'You have no idea what you need?', I doubt that. Hence we continue to live with customer requirements that are hard to articulate and unclear.
- There needs to be a designated product owner for a product. The job of the product owner is not just 'talking' to customers but much more than that. This is where most product owners fail. I've come across product owners that are totally customer focused and detached from the development team. They have no clue as to what has been shipped and what has not. On the other hand, I've come across product owners that are totally development focussed and lose sight of the customer. It has to be a balance.
- If everyone in the team ends up talking to real customers (or end customers) then who is going to do all the work? It is not possible for an individual to talk to real customers, 'Observe', 'Frame', 'Brainstorm', and 'Build' at the same time. It is different if your customer is not an end customer but maybe an intermediate upstream/downstream team that is using/supporting your product.