It has been a while since I posted a blog entry directly to blogger.com (though I hope that some people are enjoying my weekly roundup of interesting findings via diigo.com).
I finally have the beginnings of a plan for a bunch of entries that will hopefully say something interesting about the connections between systems thinking, design thinking, agile methods and business modeling.
I suspect that it is going to take quite a while for me to formulate this out (think years rather than months), but I just watched a talk by Tim Harford (known from the "undercover economist" books and newspaper columns) at TED Global 2011, that I think is a good way to kick things off, since it made a lot of sense to me and brings together the iterative and exploratory methods of both agile and design thinking for innovation with a degree of structure:
The basic premise is a simple one; the world is too complex for us to be able to find solutions to issues by thought and analysis alone, we need to accept that we do not understand everything and, more importantly, accept that trial and error is a valid way to find solutions. As Harford says, this is obvious, but not accepted (check out some of my earlier posts on common sense solutions not necessarily being applied).
Having accepted this premise, the key thing in my eyes is to work out how to become great (and efficient) at trial and error - that is, learning incrementally from what we do and the agile, design thinking worlds have a lot to offer on that front, be it sprints, retrospectives, exploratory design, customer centric learning. Add to this the rigour of systems thinking approaches to build better understanding of complexity to building or support decision-making frameworks and you have a winning combination.
More to follow.
Here is the video:
Showing posts with label scrum. Show all posts
Showing posts with label scrum. Show all posts
Saturday, 23 July 2011
Saturday, 15 January 2011
Monday, 7 June 2010
Scrum, agile and "real' project management methodologies
I have been following a blog "Better projects" for a while. A recent post arguing that "scrum" (an agile software development methodology) can represent a complete answer to project management for certain projects, reminded me that I had been intending to post a couple of thoughts on this matter myself:
In my humble opinion, agile project management (as a philosophy, rather than the specific flavour of agile suggested by Jim Highsmith - see also here for more on that), informs all areas of project management and the application of the principles found in and around the agile manifesto, can certainly provide answers and guidance to most/all parts of a project.
This does not, however, necessarily mean that scrum can entirely replace "real" project management methodologies.
In the context of full disclosure, I feel I should out myself at this point as a fan of agile approaches in general and - on the whole - of scrum as a specific flavour of agile (though, as with any methodology it has advantages, disadvantages and should be applied carefully, taking into consideration the context of the actual project...).
A few years ago, I did a bit of thinking about how the various agile frameworks map to the various project management disciplines and how they can effect the degree of risk on a project as part of a Masters degree that I did in my spare time. Back then I came (amongst other things) to the following conclusions:
It should be noted, that this thinking was done in an academic context and consequently involved a good deal of defining and differentiating terms (eg. agile "philosophy", "method", "methodology", "approach", "framework"), but I still absolutely stand by the findings (and they have been stated in the meantime several times over by many people much smarter than I (see also here for more details from someone who really understands this stuff in detail!): any framework is just that, a framwork - it does not replace thinking and applying one's knowledge to a given environment and project to adapt and use a framework.
I have nevertheless attached a few of the overview diagrams from the introductory/definitions section of the paper below for those that might be interested:
1. "Framework" for the analysis that combined "pure" project management and software development frameworks (since I argued that many of the agile project management approaches stretch across areas of both such frameworks):
2. An overview of how scrum and xp map to this framework
3. The resulting mapping of these methodologies to the idealised framework (where a "full-score" would be attained if all areas were fully addressed - unrealistic for any framework).
If you are interested in more detail and the other findings (based upon survey and case-study, and more explicitly describing the ways in which different types of risk are addressed using agile methods), please contact me directly, since the material cannot be shared in its entirety without permission from the university, myself and the participating companies.
In my humble opinion, agile project management (as a philosophy, rather than the specific flavour of agile suggested by Jim Highsmith - see also here for more on that), informs all areas of project management and the application of the principles found in and around the agile manifesto, can certainly provide answers and guidance to most/all parts of a project.
This does not, however, necessarily mean that scrum can entirely replace "real" project management methodologies.
In the context of full disclosure, I feel I should out myself at this point as a fan of agile approaches in general and - on the whole - of scrum as a specific flavour of agile (though, as with any methodology it has advantages, disadvantages and should be applied carefully, taking into consideration the context of the actual project...).
A few years ago, I did a bit of thinking about how the various agile frameworks map to the various project management disciplines and how they can effect the degree of risk on a project as part of a Masters degree that I did in my spare time. Back then I came (amongst other things) to the following conclusions:
- There is little that is contradictory between more traditional project management "meta"-frameworks like the PMBOK from PMI and agile methods though they do not bear direct comparison in all areas and in some areas they extend into software development (ie. domain specific disciplines) not covered explicitly by project management frameworks.
- Conversely, PM frameworks do address explicitly areas that are only implied or hinted to in agile.
- As such scrum can usefully be augmented by other practices (particular in the area of HR, but also in procurement, risk management, cost management etc.).
- Usage of scrum (and other agile methods) can lead to a reduction in risks on projects
- ...But this depends entirely upon the way it is applied.
It should be noted, that this thinking was done in an academic context and consequently involved a good deal of defining and differentiating terms (eg. agile "philosophy", "method", "methodology", "approach", "framework"), but I still absolutely stand by the findings (and they have been stated in the meantime several times over by many people much smarter than I (see also here for more details from someone who really understands this stuff in detail!): any framework is just that, a framwork - it does not replace thinking and applying one's knowledge to a given environment and project to adapt and use a framework.
I have nevertheless attached a few of the overview diagrams from the introductory/definitions section of the paper below for those that might be interested:
1. "Framework" for the analysis that combined "pure" project management and software development frameworks (since I argued that many of the agile project management approaches stretch across areas of both such frameworks):
2. An overview of how scrum and xp map to this framework
3. The resulting mapping of these methodologies to the idealised framework (where a "full-score" would be attained if all areas were fully addressed - unrealistic for any framework).
If you are interested in more detail and the other findings (based upon survey and case-study, and more explicitly describing the ways in which different types of risk are addressed using agile methods), please contact me directly, since the material cannot be shared in its entirety without permission from the university, myself and the participating companies.
Subscribe to:
Posts (Atom)