Viewing entries in
Project Management

Comment

Successfully bootstrapping a large scalable Scrum practice at Royal Dutch Shell

Today, I will be presenting my paper at agile 2012. Here is the abstract for this work:

We will present the saga of a successful transformation from a struggling software development group to a scalable Scrum practice within Royal Dutch Shell. This group of sixty individuals encountered many obstacles on their journey to carry on the development of a large, 25 year old, legacy application. You will see how, over two years, we implemented a set of organizational, technological, procedural, and cultural changes to lead this group forward. Finally, we will present our vision to further strengthen and accelerate this value delivery system.

You can download the slide deck and the article itself.

Comment

1 Comment

Things to think about before and after a daily stand-up meeting

Daily stand-up meetings are at the core of the Scrum process. They help synchronize the team and quickly escalate impediments. Regardless if you have been participating in those meetings for years or you are just starting today, Mike Griffiths just published two useful posts to help us get more out of this critical activity:

1 Comment

Anchoring Effect

Comment

Anchoring Effect

Anchors

According to wikipedia:

Anchoring or focalism is a cognitive bias that describes the common human tendency to rely too heavily, or "anchor," on one trait or piece of information when making decisions.

This is a dangerous bias that can bite you when you are estimating tasks or stories in an Agile environment. I am even wondering if this plays a role when you are poker planning, and how much this influences your decisions from the get go.

Anyway, this article goes into detailing the anchoring effect and the "You are not so smart" blog is providing insights on common human behavior that plays an important role in software development.

While the phenomenon is well-known, I am wondering what a team can do about it. How can you overcome its nefarious effect and also how do you measure its effect in the long run.

[via You are not so smart]

Original photo by Plbmak

Comment

Comment

A Pattern for Using Scrum and Kanban

For a while now, I have wondered how you can combine Scrum and Kanban. Scrum is a good lightweight method that, if applied properly, can improve productivity, and more importantly, transparency for all stakeholders. On the other hand, Kanban seduced me for its simplicity and its ability to streamline your development. However, I never read anything about combining the two and most articles I have read so far seems to portray those two methodologies as oil and water. This article take a different approach and shows how a well lubricated and performing Scrum team can benefit from Kanban.

This is food for thought.

[via AvailAgility]

Comment

Comment

Adapting Steven Covey's concept to retrospectives

In Seven Habits of Highly Effective People, Steven Covey describes the concept of circles of control, influence, and concern. Succinctly, this concept states that you should only focus on the few things you can control and influence, and not on the many for which you are powerless.

This article describe an innovative retrospective process that one can use to help focus a Scrum team on the items they can control or influence.

This is a nice idea.

[via Partnership & Possibilities]

Comment

Comment

Agile Anti-Patterns

I believe that Agile is a great tool to help development teams achieve more, improve, and reach their next level in effectiveness, productivity, or creativity. However, like any tool, it can be misused or misapplied. You can shoot yourself in the foot if you are not applying a certain level of discipline or hygiene.

Mike Griffiths posted a short and sweet article on this subject that he entitled Agile anti-patterns. He classifies those anti-patterns as follow:

  1. Agile as a silver bullet
  2. Agile as an excuse for no discipline
  3. Agile without explanation
  4. Shallow Feedback

Comment

Comment

If You Want Something Done, Practice Your Patience

PatienceAs a manager you've been taught, either by your peers, or through hard knocks, to avoid micromanaging your teams. You quickly learn that micromanagement only alienate people. Anyway, I have noticed that delegation appears to be a difficult concept for inexperienced managers that I had the opportunity to mentor. Delegation does not come naturally. Newly appointed supervisors often think “If you want something done, do it yourself.”

Delegation of authority is an investment and you need patience and time to see your investment come to fruition. It may take a few weeks, a few months, or a year but your patience will be rewarded in the end.

This is the theme of Jurgen Appelo's humorous article.

[via NOOP.NL]

Original photo by mrsmas and published under SXC license.

Comment

Comment

Patterns and Practices for Distributed Teams

TimezoneIf you are working with teams distributed across multiple timezones, you know how difficult it can be to operate efficiently at times. Over the years, you surely have experimented and tried out different patterns or processes that work in your context. I have been working for ten years with teams that were in timezones seven to thirteen hours away from my own and we have experimented quite a bit. This is fun and frustrating at the same time.

J.D. Meiers exposes some patterns and practices that will work with distributed teams. I have found that those patterns are not appropriate in every circumstances but they are an excellent summary that will prevent you from reinventing the wheel

[via J.D. Meier's Blog]

Original photo by extranoise and published under an Creative Commons Attribution License

Comment

Comment

Kanban - The Next Step in the Agile Evolution?

I am interested in everything that can help improve my teams' productivity and consequently helps us provide better value to our customers. As such, I have started reading about Kanban, a project management methodology that appears to "compete" with Scrum. Scrum is the methodology that I am currently using. Scrum is an iterative method that provides incremental value to stakeholders at the end of each iteration. The product owner provides requirements at the beginning of each iteration. During the iteration, the team designs, implements, tests, documents, debugs new features based on those requirements. At the end of the iteration, the team demonstrates the new features to the product owner who accept or reject them.

Kanban on the other hand, is not an iterative process. The product owner provides ranked list of requirements. The team pulls requirements from top of the list one at a time. The team designs, implements, tests, documents, debugs new features based on those requirements. The product owner review the new features as soon as they are produced.

Project Management Hut presents an article describing Kanban as the next step in Agile Evolution.

[via The Project Management Hut]

Comment

Comment

Agile vs. Waterfall: A Tale of Two Teams

We are using Agile methodologies at work and I was looking for ways to explain the fundamental differences between those two development methodologies. It turns out that this video is pretty good at doing just this. Enjoy... httpv://www.youtube.com/watch?v=gDDO3ob-4ZY

Comment