PUBLIC MARKS from greut with tag agile

I’ve written previously about my allergic reaction to process maturity models for Agile development. Based on 5 years of empirical feedback being a part of or watching what  succeeds versus falls back, I do not believe their is a “cookbook” for Agile adoption

no cookbook

As Morpheus would say: There is a difference between knowing the path and walking the path. Your first sprints will probably fail. Ours did. But you have to keep going.

Quotes from the Matrix always look cheesy

The Chicken Test

If it walks like chicken and clucks like a chicken, it probably is a chicken. And if the team is treating you like a chicken, then you are probably acting like a chicken.

After all, a cargo cult shop is imitating what they have seen about agile. However, like waterfall proponents, cargo cult agile shops are led by people who have looked at pictures of agile models, "read" agile books, or "learned" agile development from PowerPoint presentations. Perhaps there are a number of developers who know agile, but they may not be able to move the company towards agility in the face of generations of managers and developers who have been indoctrinated by DoD-2167.

the story of my life

WAgile, as all know, stands for "Waterfall-Agile", and is the pinnacle of dysfunctional development methodologies.

Or maybe we need to stop selling Agile. Maybe we need to say, "Agile is hard, and you can't master it by sitting through a two-day course." Maybe we need to be firm and say, "Sorry, if you don't use agile engineering practices, if you don't have high-bandwidth communication, and if you don't include a strong customer voice, you're not going to succeed. Try something else instead." Scrum is popular because it's easy--and that's part of the problem.

Is that linked to the cargo cult thingy?

This is an evolving web version of a book that I'm writing titled "Zero to Hyper Agile in 90 Days or Less."

a book as a blog.

This book aims to give you a head start by providing a detailed down-to-earth account of how one Swedish company implemented Scrum and XP with a team of approximately 40 people and how they continuously improved their process over a year's time.

another (free as in beer) book to read

The best way to implement code quickly is to implement less of it. The best way to have fewer bugs is to implement less code.

Once the tasks are prioritized and in the bullseye, you can organize, arrange and add structure. You can start to see relationships, which may indicate a different priority. You can start to see categories, which may affect iteration planning. You can begin to add structure. The outcome of this exercise is an easily understood diagram showing the project’s priorities. For teams that aren’t comfortable assigning a number to a task, this is a good alternative to try.

Something more interesting than the usual Excel sheet

Great software requires collaboration and communication. Fit is a tool for enhancing collaboration in software development. It's an invaluable way to collaborate on complicated problems--and get them right--early in development.

Fit allows customers, testers, and programmers to learn what their software should do and what it does do. It automatically compares customers' expectations to actual results.

How this can work with some web app requirements?

Squeejee believes that billing hourly offers more flexibility and cost savings for our client and is fair to us. Now that’s a win-win.

Using Evidence-Based Scheduling is pretty easy: it will take you a day or two at the beginning of every iteration to produce detailed estimates, and it’ll take a few seconds every day to record when you start working on a new task on a timesheet. The benefits, though, are huge: realistic schedules.

Realistic schedules are the key to creating good software. It forces you to do the best features first and allows you to make the right decisions about what to build. Which makes your product better, your boss happier, delights your customers, and—best of all—lets you go home at five o’clock.

A more general approach that the SCRUM one I got so far.

Build your business practices to embrace change just like your Agile development practices do. Embrace continuous integration of the enterprise, not just your source code.

yes, embrace it