Just heard about agile software development or Scrum and want to know more about it? Here are 3 books which will get you started and maybe tempt you to take the blue pill:
1. Agile and Iterative Development: A Manager’s Guide: This one gives you a high level overview of everything agile, including Scrum. Good to get a first basic understanding of agile principles and methodologies / practices around town.
2. Agile Project Management with Scrum: This is the reference book on Scrum written by Ken Schwaber. A must read for anyone who has already a pretty good idea of agile principles and is considering Scrum.
3. For the German speaking audience, Boris Gloger’s book “Scrum: Produkte schnell und zuverlässig entwickeln” provides excellent materials. For the record: I was lucky to have Boris as my trainer for my CSM training.
What would you recommend for someone willing to know more about agile software development?
Whoever you are, this is just to let you know that I have moved this blog’s RSS feed to Feedburner. You should probably update your favourite RSS feed reader with the new address: http://feeds.feedburner.com/njaminblog
The previous location is now redirecting to this address too.
Sorry for the inconvenience caused.
If you work in a matrix organization, it may well be that you have a small pool of designers doing all UX work. They usually have work coming out of their ears and are put under heavy pressure to feed development teams with HTML (or other) templates.
Since UX is actually a core element of a product, how does it all fit with your definition of done? Do you usually wait to have all UX items delivered before starting the project? Is the designer also delivering incrementally? Either way, how does the development team cope with this?
In short, how do you do it and why?
Update: The discussion has started in the LinkedIn Scrum Practitioners group.
As I mentioned a couple of weeks ago, I wanted to spend some time writing down the commonalities and differences between the Project Management Body of Knowledge (PMBOK) and Scrum. This post is an attempt to outline some high-level points that characterizes the 2.
PMBOK = set of guidelines | Scrum = values + tools
First and foremost, the main misconception from those who don’t know about PMBOK, is that it is a methodology that should be strictly followed and involving never-ending documentation. It’s not. PMBOK is a set of guidelines, that have been identified as being critical for successful projects delivery. It is up to the project manager, together with the stakeholders, to define what processes should be used and to which degree.
Scrum on the other side, is a combination of a values and tools based on the Agile Manifesto aiming at delivering (mostly but not only) software projects. Scrum values and artifacts are clearly defined and not following them means you’re not doing Scrum.
How does Scrum fit in the PMBOK (or not)?
1. All the values and artifacts present in Scrum fit in the PMBOK Knowledge Areas (Integration, Scope, Time, Cost, Quality, Risk, Procurement, Human Resources, Communication): Sprint planning, Sprint review, Product Backlog, estimations, team building, PDCA wheel (continuous improvement), doing the risky stuff first, defining ‘done’, close customer relationships, measuring success, daily Scrum, iterative planning – it all fits in the PMBOK Knowledge Areas, only with a different vocabulary. Again, it’s up to the project manager, together with the stakeholders, to define how all these areas should play together.
2. Both are embracing change: Scrum embraces change by allowing features to come in and out of the Backlog. PMBOK has a slightly different approach: simply put, any change request should be documented, reviewed by a defined set of people, added to the WBS if accepted and updating the various baselines (scope, cost, quality). Actually let me rephrase my point with Scrum: the Product Owner is responsible with what comes and goes in and out of the Product Backlog. Yes, that’s right, again Scrum fits in the PMBOK when it comes to change management.
3. Project values drive how the project will be managed: Scrum wouldn’t be what it is without the underlying values of the Agile Manifesto. When projects start with Scrum as basis, the direction is clear as to how the team should work together. When PMBOK is used as basis for projects, there is no pre-defined set of values to guide the team: it’s up to the project manager, together with other stakeholders, to define the project values and use the tools or define the processes that will be aligned with the projects values the various stakeholders committed to.
It’s all about people
This post is in no way exhaustive, however it illustrated how I see Scrum fit within the PMBOK. As a final word, I would say (actually repeat) that project are successful because of the people that make them. The project manager needs to understand this in order to define the project values, together with the team, that will drive how the project will be executed.
Looking forward to your comment and feedback!
