A project I’m aware of recently started discussing in their retrospectives that they wanted to start assigning points to tech tasks. I’m a big believer in allowing a team to exercise control over its own process — so in my mind the right answer is to let the team make the call. I do have some thoughts … Continue reading
Tag Archives: agile
Organizational Risk: Building Trust
In my last post, talking about Organizational Risk, I advocated for a meeting once per iteration with members of different departments to reduce the kinds of project throughput risks that can stem from an dev team practicing agile working within a larger waterfall oriented organization. What might a meeting like this look like? Infrastructure & … Continue reading
Organizational Risk
Transforming an organization is a difficult business. One common pattern is the development team takes up the charge, practicing scrum and XP techniques. However, they may find their agile team working with a waterfall oriented Enterprise Architecture and Web Operations department. There’s an impedance mis-match here that can result in risk to your project, particularly … Continue reading
How to Avoid Problems with the StranglerApplication Pattern
Recently I noticed a question on StackOverflow that seemed to indicate that a project had encountered problems with the Strangler Application pattern. The basic premise behind the strangler is really great: instead of trying to do a “big bang” style all at once replacement of a legacy system, you instead build a strangler application by making … Continue reading
Who should be the architect in an agile project?
I came across this question on Programmers.Stackexchange.com today: We are developing the agile way for a few months now and I have some troubles understanding the agile manifesto as interpreted by my colleagues. The project we are developing is a framework for future projects and will be reused many times in the next years. Code … Continue reading
How Do You Estimate Software Projects?
Make sure that the specification is broken down in to user stories. Estimate each user story individually. Give each user story a 1 day, 2 day, or 3 day estimate. If you think a story will take more than three days, break it in to smaller pieces. Even if you think it will take only … Continue reading
Software Development 