newyorkscot

Risk Mgt View Of Scrum September 16, 2005

Been reading 'Agile Software Development with Scrum' by Ken Schwaber, Mike Beedle, and saw these great risk factors Scrum specifically addresses (Section 6.3):

• Risk of not pleasing the customer: customer gets to see the product on a continuous basis
• Risk of not completing all functionality: functionality is developed in a prioritized way through Sprints, ie high priority functionality is delivered, and only low priority is missed
• Risk of poor estimating and planning: Daily scrums provides small estimates that are tracked within a Daily Scrum cycle and through the invariant set of Product Backlog assigned to the Sprint cycle.
• Risk of not resolving issues promptly: Burden of proof on management by requiring daily active management. In Scrum, role of management is bi-directional so that mgt reports to the staff on how it is resolving issues during Daily Scrum.
• Risk of not being able to complete the development cycle: Scrum ensures that there aren't any major problems with the development cycle by delivering working software every Sprint. This forces issues to be dealt with.
• Risk of taking on too much work and changing expectations: Scrum disallows any changes in the Product Backlog associated with a Sprint so that the team feels their goal is respected and the customer has clear expectations.

How To Fail With RUP August 22, 2005

Check this out – decent explanation of what people do wrong with RUP.

Insider’s View On Agile June 24, 2005

This is from someone inside our client base who has also tried to sell & manage Agile projects….
The issue with selling (and managing) Agile projects is maintaining the balance between rapid delivery and controls. Traditional projects that businesses are used to following expect a roadmap, milestone dates, dependency dates and anticipated ends with expected functionality. With Agile methodologies, requirements are developed as you go and the end state is less predictable. Keys to success include tightly managing expectations and setting guidelines for each iteration. Selling these types of programs are difficult because they don't fit within the traditional framework – if you can walk through a project lifecycle and build the predictability by setting tight guidelines for estimations, time spent on an iteration, level of detail spent on each component at any given time, building a working end-to-end system albeit "rough" functionality in the first few iterations I think you can demonstrate the benefits of the methodology and mitigate the risks.
Also, large companies and large programs will worry about the forecasting of key dependencies on integration points with other systems. You will need to accout for that as well.
In the end you will create a hybrid traditional/Agile methodology to enable you to gain the speed and agility of rapid iterations with the controls, planning and forethough of integration.

Agile Selling or Selling Agile ? June 23, 2005

I suspect this will be the first of many entries here, so here goes with the can of worms: How do you sell an agile approach to delivering projects, factoring in the needs/issues/barriers of the folks in the client: PMs, CTOs, vendor mgt, legal, CFOs ?

We can create the nice glossies and presentations talking about this, that and the other benefit of agile methodologies (whichever one or combination you prefer), but there is more to it than this.

My take on it is more to do with the classic ‘Solution Selling’ approach: block & tackle question model whereby there are three main lines of questioning : diagnose, explore impact and visualize capabilities, each with a subset series of questions: open, control, confirm… (btw – this Solution Selling is probably another blog entry for the future). The point is that you need to understand the business problem and pain (or latent pain), and then apply your judgement (and agility) as to how you can solve their problem quickly and effectively. I think this is a pragmatic and experiential sell – you need to know your stuff, but be able to iteratively work out the right approach for the problem – sound familiar ?

Others have blogged about the legal side of things, which I think requires a shifting of the mindset on the side of the clients’ legal/vendor mgt. It almost like you have to disprove the status quo and show that they business NEVER gets it right first time, and that quick meaningful deliverables (production quality) is actually what the business wants.

As I said, this was just to open up the can of worms. Any first hand experience of others in selling agile approaches to non-buyers would be appreciated …