Over the past two weeks I have been fortunate enough to be allowed to run 5 workshops on Agility in general. While these have been sales or marketing funded, I was allowed to run them without any interference and we were able to come up with some great interaction and engagement. One thing I did promise to each workshop was that any question I couldn’t answer during it I would type up and send out in a follow up email. Below is a collection of all the unanswered questions I was able to gather, I hope I didn’t lose any, but it is entirely possible with some of those hotel wonder-surfaces that are so resistant to post-its.
If I missed your question here just post it in a comment, I’ll see about getting it answered as soon as I am able. So without further delay:
— When to apply Agile vs Hybrid-Waterfall?
Hybrid-Waterfall *could* be Agile depending on what you are doing. I find a common misconception that we don’t do Up-Front planning in Agile often leads to this question. Always remember that the Product Owner decides what needs to happen to create our product and the order in which all the whats happen in. This means that a Product Owner could quite legitimately have the team do a lot more up front with estimation and analysis. When to do that however? That’s likely going to be a business decision that I always suggest is well informed. Work we spent analyzing and planning things that we never do is simply waste, and would have been better spent actually building something if that were possible.
— How do I get the team and stakeholders to get on board with moving forward with Agile practices?
This is one of the places that Agile Coaching becomes critical for most organizations. How you do this is pretty heavily dependent on your organization. I would say that something to keep in mind is that in our experience organizations that start with one important (but not the most important) project to apply Agile to, and give that project their all, (including finding people who want to try this and volunteer to do it) works much better then trying to apply Scrum to an entire organization. Pockets of strong agile practice and culture spread to the rest of the organization, where as a very broad but shallow adoption tends to lead people to fall back on old bad habits before giving it the time it needs to start working.
— Do you have tips for rolling up agile projects onto a dashboard portfolio?
First tip; do everything on purpose. Reports should inform a decision. Metrics must be fully understood if they are to be used. Often what seems to end up on such dashboards is a collection of just…stuff, that looks neat but maybe does nothing or very little. If you have software giving you reports automatically, as a by product of simply doing your work, those can be fine because they are little or no cost to product.
As to the specific things that I think are useful, I’d suggest having a look at Mike Cohn’s burndown: http://www.mountaingoatsoftware.com/agile/scrum/release-burndown/alternative
It’s a little hard for many people to understand, which is why I usually express it in a burn up plotted every day on 2 lines, but if you can internalize what that report is saying and why you have a great place to start when it comes to Agile metrics.
I would also suggest finding some way to display (in a read only format) your Product Backlog(s). Always remember that a well groomed product backlog is a sort of a report in and of itself, telling you a lot of very useful things, especially if you use your velocity calculations to pencil in the currently estimated block of work that will make it into a fixed date release.
In truth this topic is way too complex for me to cover in this blog post, but if you like you can contact me and we can schedule a webex to cover exactly how we’ve solved some of these problems with our own software at Collabnet.
— How to transform iterative methodology into Agile.
I have good news, Iterative is Agile. It isn’t however Scrum, which I suspect may be the real question here. Usually when people describe to me their Iterative process what I get is a description of Scrum with less discipline and looser engineering standards, tooling, and practices. The best way to get better at your Iterative process is with the use of regular Retrospectives examining options for improving your process, and in particular I would suggest looking deeply into Scrum to see how close to that you can get.
— Most Common Mistakes made in unsuccessful agile and/or the key things for success.
I could list things all day here probably. There’s a myriad of things that lead to failure or success with agile, but f you get to the root of what I see most often it’s usually two things; A culture rooted in 20th century assembly line thinking and a lack of true Product Ownership.
— Do you produce (or need) Rapid Prototype using Scrum methodology?
To be honest I’m not 100% certain what is meant by Rapid Prototyping here, but if it’s what I am reading about online the concept of making something that can be shown to the end user is absolutely core to Scrum. I would say that if you are doing some form of Rapid Prototyping now for feedback purposes that you are likely already undertaking engineering practices that will work very well with Scrum. If anything you may find that Scrum simply makes your prototyping work even better.