This is Allan Kelly's Typepad Profile.
Join Typepad and start following Allan Kelly's activity
Join Now!
Already a member? Sign In
Allan Kelly
Recent Activity
I can feel you are thinking the issue through as your are writing this, and I think your conclusion could be broadly stated as "Don't do it." Which is kind of how I feel myself. But I also recognise that some people feel they have a need to do "big". Bluntly, Software development is difficult to do in the big, however you do it, Agile or otherwise, you are going to have problems. Therefore avoid "going large" if you possibly can. I blogged about this myself last year (http://allankelly.blogspot.co.uk/2013/08/scaling-agile-heuristics-safe-or-not.html) if you want my full version but basically.... When people say "How do you scale Agile?" I think they are actually asking one or more different questions: - How do you do Agile with a big team? - How do you do Agile with multiple teams? - How does an organization govern Agile work? Each question has its own answer - which might be combined - but each started with "get good at doing it small." I've come to think that while people may think they need Big Agile I don't think thats the problem most of them have. The problem they actually have is doing any Agile. But there are those people see an opportunity to sell Big Agile so they've defined such a problem.
Toggle Commented Jun 19, 2014 on The Folly of Scaling Agile at Agile Coaching
1 reply
Yes my thinking is similar. I think estimates can be useful: - for the team (understanding work, selecting work etc.) - in the short term (next 2 weeks good, maximum 12 weeks out) I have a long blog from last year about my thinking, if you don't mind me linking http://allankelly.blogspot.co.uk/2013/04/to-estimate-or-not-to-estimate-that-is.html I agree with much of what the #NoEstimates gang says although I feel there is a bit of "throwing the baby out with the bathwater". The mis-use of estimates (usually beyond the team and far into the future) causes a lot of problems. And sometimes the information conveyed in an "effort estimate" isn't really that useful (particularly if people remember they are *estimates* not promised.) My standard line for longer range work these days is to: Forward planning should be value not effort based. So I ask the business to estimate business value before any effort estimates are made. (They can do this using planning poker just like effort estimation.) If nothing else it gives the business folk a new appreciation of the difficulty in estimating. Developers sometimes find it amusing to here the business folk trot out all the old "I can't estimate because..." lines which the business usually criticise.
Toggle Commented Apr 7, 2014 on Estimates Considered Useful at Agile Coaching
1 reply
Interesting idea, I think about Conway's Law a lot in my work, and Reverse Conway's Law when the org becomes a copy of the system. The homomorphic force works in both direction. SOLID for teams is an interesting idea but I'm not sure it takes us anywhere. I'd rather think about what we want from teams and then decide what the mnemonic would be. Continue this at XP Day
1 reply
I just don't see the point of Sprint burndown charts. The board (should) tell you what you need to know. Burndown charts spanning several sprints, now they are damn useful. Nor do I like the idea of someone leading a stand-up meeting by asking people how long it will be before its done. People might volunteer this information and I'd hope the way of tracking work would make people feel good about completing things but hours left? Pointless in my view.
Toggle Commented Jun 7, 2012 on Busy Burning Down Sprint Tasks at Agile Coaching
1 reply
Allan Kelly is now following The Typepad Team
Jun 7, 2012