Agilish

No, really. Stop for a second and ask it plainly: what is the problem here? If we are doing projects, we are problem solving. We are trying to help our business run more efficiently, compete more effectively, or do something it could not do before. That is the whole point. Everything else — the methodology, the tools, the ceremonies, the frameworks — is in service of that goal. Not the other way around. The Problems Come in Every Shape and Size No two projects are the same. The business problem might be a spreadsheet that one very clever person built five years ago to track customer orders, and which now has 47 tabs, three people who understand it, and zero ability to scale. Converting that into a real system that can be supported and maintained is a genuine problem worth solving — and it looks nothing like building a new customer-facing mobile app from scratch, which looks nothing like upgrading a twenty-year-old core banking platform that nobody wants to touch. The permutatio...

I have lived through this more than once. You walk into an organization, you can see clearly that Agile would make things better, and you hit a wall. Not a wall of bad intentions — most of the people involved are smart, experienced, and genuinely trying to deliver good work. The wall is something older and harder than that. It is culture. It is history. It is the accumulated weight of a command-and-control framework that has been built up over years, sometimes decades, and that has been working well enough that nobody with real power has had a reason to change it. And then you show up and tell them they should. Why Large Organizations Struggle The Agile Manifesto was written in 2001. But mainstream adoption — real adoption, not just putting "Agile" on a job description — did not come until much later. And even today, after more than twenty years, plenty of large organizations are still working through it. That is not laziness. It is complexity. Think about what it a...

ag·il·ish /ˈajəliSH/ adjective Able to apply Agile values and principles to execute a plan quickly and easily. "The team worked in an Agilish way to meet their deadline in spite of unplanned obstacles." Relating to or denoting a method of project management characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans. "Agilish methods apply Agile concepts to different types and sizes of projects." The World Agile Assumes The Agile Manifesto was written in 2001 by seventeen practitioners who believed — rightly — that there was a better way to build software. The values and principles they articulated have stood the test of time. Incremental delivery, collaboration, responding to change, working software over documentation — these ideas work. The evidence is overwhelming. But the Agile Manifesto was not written with a Program Management Office in the room. It was not written with a heavily regulated ...

par·kin·son's law noun — "Work expands so as to fill the time available for its completion." — C. Northcote Parkinson, The Economist, 1955 In a previous post I wrote about Ron Jeffries, the co-founder of Extreme Programming and the man credited with inventing story points. One of Jeffries' core arguments — and the reason he eventually grew to regret story points — is that estimation tends to become a target, and once it becomes a target it stops being useful. Teams stop working toward delivering value and start working toward hitting a number. There is a law that explains exactly why this happens. It has been around since 1955 and it has nothing to do with software. But it describes software teams perfectly. What Is Parkinson's Law? Cyril Northcote Parkinson was a British naval historian who published a satirical essay in The Economist in 1955. In it, he observed something that anyone who has worked in a large organization will immediately recognize: w...

Estimating Software Projects is a Conundrum. co·nun·drum /kəˈnəndrəm/ noun — a confusing and difficult problem or question. The problem to solve is this: when you work at a company that has a Program Management Office (PMO) and/or is highly regulated, the business partners that sponsor and regulate projects expect accurate estimates for the work you are going to do. They also expect evidence that you are delivering on those estimates. At the same time, large projects tend to take a long time. It may not take long to deliver working software into production if your team is good, but to "finish" a project — such as a re-platform or a large scope of work — can take months if not years to complete. And over the course of that time, things change. Business priorities change. Technologies change. Your budget will change. The people on your project team will change. The longer a project needs to run, the bigger the challenge with estimating and delivering the software that...

I have had many discussions and some arguments about story pointing and project estimating over the years. One day I got so frustrated with a colleague that I decided to go to the source. The cool thing is that I think I found the source! Ron Jeffries is credited with being the inventor of story points. Ron is one of the original seventeen signatories of the Agile Manifesto and a co-founder of Extreme Programming (XP). I think this video is fantastic and must-watch for anyone trying to figure out how to estimate Agile projects with any kind of accuracy The Genesis of Story Points I don't usually so this, but I also don't usually get authenticate message like this from the horse's mouth either. I have included main points of the transcript below. I don't promise to tell the story the same way every time, but it's worth noting that on the first XP project we started with a large-scale estimate. As it happened, we had a complete set of storie...

After many races, lessons, and retrospectives, the Hare and the Agile Coach had become quite skilled at running their course. The path was simple. The flags were clear. The finish line was always in sight. But one morning a messenger arrived carrying a large stack of papers. “These,” said the messenger, “are requirements from the Project Management Office.” The Hare stared at the pile. Forms. Reports. Schedules. Approvals. “If we carry all of this,” sighed the Hare, “we’ll never reach the finish line.” The Agile Coach scratched his chin thoughtfully. “Governance is not the enemy,” he said. “But we must be wise about how we carry it.” The Tortoise slowly stepped forward. “Let me take the load,” he said. The Hare blinked. “That stack is enormous!” The Tortoise smiled. “I may not be fast,” he said, “but I am strong. And I am patient.” So the team made a plan. The Hare and the Coach would run the course, ...

An Agile fable about cleaning the path before it slows everyone down. One evening the Hare and the Tortoise visited the wise old Owl. They had been running many races and placing many flags. But the path had become cluttered. Old flags leaned sideways. Some had fallen over. Others pointed in the wrong direction. The Hare sighed. “This course used to be easy to follow.” The Tortoise looked at the tangled flags. “Now it is confusing.” The Owl blinked slowly. “You have been adding many improvements,” he said, “but you have not been cleaning the path.” The Agile Coach nodded. “That’s true.” “So what should we do?” asked the Hare. “Spend some time repairing the course,” said the Owl. The next day the team worked together. They removed old flags. They replaced broken ones. They straightened the path. By afternoon the course was clear again. The Hare ran the race once...

An Agile fable about keeping the race manageable. One afternoon the Hare and the Tortoise were planning their next race. The Agile Coach had drawn a simple path across the field with four flags marking the milestones. “Run to each flag,” he explained, “and you will reach the finish quickly.” Just then the Fox appeared. “What a wonderful race you’re planning!” he said. “Thank you,” replied the Hare. “But wouldn’t it be even better,” said the Fox, “if the race also included a hill climb?” The Hare looked interested. “Well…” “And perhaps a river crossing,” continued the Fox. “That might be fun,” said the Tortoise. “And maybe,” the Fox added excitedly, “a maze through the forest, a bridge over the stream, and a loop around the mountain!” Soon the race path was covered with new lines and twists. The flags were moved again and again. The starting time came and went. Finally the Hare sighed. ...

An Agile fable about learning after the race. After the great rematch race, the Hare, the Tortoise, and the Agile Coach became something of a team. They trained together, ran together, and occasionally celebrated together. But one morning the Hare arrived at practice looking frustrated. “I keep getting faster,” he complained, “but sometimes things still go wrong. Yesterday I ran the course and tripped over one of the flags!” The Agile Coach nodded thoughtfully. “That happens,” he said. “Speed is important, but learning is even more important.” The Tortoise tilted his head. “What do you suggest?” “A retrospective,” said the coach. They sat together beneath a large oak tree and began discussing the last race. “What went well?” asked the coach. “The flags helped me stay focused,” said the Hare. “And the spacing made the course easy to follow,” added the Tortoise. “Good,” said the coach. “Now, what ...

A modern fable about speed, humility, and incremental delivery. After losing the famous race to the Tortoise, the Hare was devastated. For days he replayed the moment in his mind—how he had sprinted ahead, grown overconfident, taken a nap, and awakened only to see the Tortoise crossing the finish line to thunderous applause. The Hare had always been fast, but now he realized something painful: speed alone was not enough. Determined to redeem himself, the Hare hired an Agile coach—another hare known throughout the forest for helping teams achieve their goals. The Agile coach listened patiently as the Hare described the race. “You were faster,” said the coach, “but you didn’t manage your progress. Let’s train for a year and build a better approach.” For the next twelve months they practiced every day. The coach taught the Hare how to break a long journey into smaller goals, how to measure progress, and how to ce...