One of the problems many people encounter when moving to agile is that they (literally) cannot imagine iterations shorter than 4 weeks. I rarely recommend an iteration as long as 4 weeks now, and if people insist on 3 weeks, suggest they find the root cause for the reason their iteration needs to be so […]
Wow! I can hardly believe how many people have signed up for the brand-new free teleclass, “3 Crucial Factors For Preventing Your Agile Titanic” that Gil Broza and I will be teaching next week! I guess we struck a nerve with many people who want (or need) to get Agile going, and who don’t have
I have a question for you: Have you come across team whose first attempt at Agile adoption resulted in conflicts, pain, or just fell short of expectations? I’ve met plenty of teams like that. I’ve heard statements like “nobody knew what they were doing”, “management still dictated an impossible deadline” and “those sprints became small
Summary: Your developers are already working feature-by-feature in iterations, but your testers are stuck with manual tests. How do you make the leap to agile testing when the nature of agile’s iterative releases challenges testers to test working segments of a product instead of the complete package? In this week’s column, Johanna Rothman explains that
I’ve been working with several clients on their transition to agile approaches to their projects. They all have a common state: Many features to implement Huge technical debt Many defects They want to get a handle on all the work they have to do. I suggested they consider three backlogs, making sure that for a
I’ve been working and speaking with whole bunch of people who want to “go agile.” They are not set up for agile. They have gates for approval. They don’t have teams that projects flow through; they assign people to whatever project whenever. (growl. People are not fungible. growl) They have geographically distributed team bits (I
In the Small Steps and Plunge In posts, I said projects should transition to agile all the way. But does it work the same way for the entire organization? Nope. I recommend a gradual approach to moving to agile. Not all project teams are ready for the self-discipline agile requires. But, even more importantly, too
I love it when my readers challenge what I’m saying, as in Plunge In or Dip Your Toe? (for Projects). I do believe in small steps for projects. I’ve long been an advocate of inch-pebbles, of standup meetings, of iterations and incremental development. I love knowing what done means, for the project and for features
Last Tuesday, I had a blast at Boston SPIN. I led a roundtable about transitioning to agile, and discovered that not everyone takes the feedback the timebox gives them. In this case, people weren’t finishing what they “attempted to commit to” in the timebox, but they extended the timebox. I suggested that was not such
I gave a talk last night at the Software Quality Group of New England about schedule games. During the talk, I explained how serial lifecycles don’t manage technical, schedule, or cost risk. Serial lifecycles actually increase the duration of the project. And, serial lifecycles don’t offer feedback early enough for the project team. (They only