No related posts.

As I commented in the post, I believe this is a key point to having a committed team that is ready to do whatever it takes to improve things.

Not only does the team have a strong feeling of being responsible (they are!) for the way things are done in the team (i.e. if we don’t do it, nobody is going to) – but having the problem defined by the whole team and the solution agreed by the whole team increases highly the chances of successfully solving the original problem.

A basic, which I thought was important to stress again…

Sorry for the lack of writing the past few weeks, I simply haven’t found anything that I wanted to blog about. Today though, when reading my feeds, I stumbled on a post from Mike Cohn promoting his newly published book. In short, you can win a copy of his new book “Succeeding with Agile” by leaving a piece of advice in the post’s comments:

To win, enter as a comment to this post the one most valuable bit of advice you would give to a team that wanted to succeed with agile. I will pick the one bit of advice I like best and send the author a copy of the book. I will also pick a second winner at random from those who submit. So, you’ve got two chances to win so let’s hear your best one bit of advice.

My piece of advice is the following: “Know why you are willing to walk down this path.” Once you know, you’ll be able to make the right decisions as to what practices to adopt, remind people in the organization in case of doubts and most importantly stay focused on what you and the team have defined as the reasons for the change.

The Lansdhuter Hochzeit is a huge celebration that takes place every 4 years in Landshut, Bavaria. It celebrates the wedding of George the Rich (son of the Duke of Landshut) and Jadwiga (daughter of the King of Poland) which took place in 1475.

For this occasion, a big part of the Landshuters are letting their hair grow and dress-up like people did then. Everything must look authentic and comply to the strict rules of the association that organizes the event. A small village is also built to reconstruct the way things looked like at that time and how people celebrated this wedding by eating, drinking and watching the infamous knight fights.

The result is a beautiful city full of colors and people celebrating this ancestral ceremony with lots to drink and eat.

I took plenty of pictures and put a small selection online: http://www.flickr.com/photos/frenchfrog/sets/72157621624331263/

Doing a small search for “laho” will show you a few more…

No related posts.

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?

The previous location is now redirecting to this address too.

Sorry for the inconvenience caused.

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.

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!

Apart from a different scale, is it much different than to adopt Scrum in a small sized company? I tend to think the same organizational and systemic dynamics come into play: company culture, senior management support, communication channels, work environment etc.

Is it the scale of everything and how deep the company culture is rooted that might make things a lot tougher?

What do you think? Can Scrum survive in the world of fixed scope and date, top-down management, lengthy weekly email reports with hundreds of recipients in CC, big bang releases with multi-million € Marketing campaigns?

I would love to read your comments on that one!

Update: Point 1 from this comment pretty much nails my thoughts on Agile in the Enterprise. It can’t work if the leaders don’t change.