Dilbert saves the Agile day

10 Jul 2016

Dilbert saves the Agile day

It is amazing to see some of the comics made by Scott Adams are already more than a decade old and are still spot-on. Today I will use 4 of them and connect them with real live challenges that are happening in our daily routines creating software.

‘One Dilbert says more than a thousand words.’

1. Chairs and pants
DILBERT © 2013 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

Silver bullets don’t exist. The same holds true for best – or good – practices embraced in Agile software development. Be aware if you are in a transforming organization and senior management pushes Agile forward to solve all kinds of problems. A few examples in which Agile or Scrum will not make your existing problems go away:
– The engineering workforce is not equipped for new projects and techniques.
– Management is not involved in your most relevant projects and is not managing or leading.
– There is no clear view on the product vision and roadmap or priorities.

Yes, often Agile working processes can help in solving these problems. Agile itself however, is not the solution to all existing problems.

2. Success of Agile just doesn’t depend on good engineers alone
DILBERT © 2003 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

For organizations to become successful in their Agile adoption, it is good to perceive the roles of business representatives and Product Owners carefully. In my opinion the most underestimated role in Agile & Scrum is that of the Product Owner. Early adopters often appointed an experienced user or analyst as the Product Owner and focused most attention on the Development Team. Sometimes this pattern can still be seen today. In a few cases it worked fine. However, often the skills needed to be a good Product Owner are much harder to find than with a quick look around. The impact a good Product Owner has on the team’s productivity and in the end the value delivered for the organization is huge. So invest in training and coaching newbies or hiring experienced Product Owners.

3. Being Agile versus Doing Agile
DILBERT © 2003 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

A lot of organizations have been in an Agile transformation for some years now. Probably a large part of those organizations claim they “Are Agile”. I guess it is more a question of perception than exact definition. In adopting a lot of Agile practices and converting existing teams into Scrum teams – or Kanban – it is easy to make that statement. But a genuine Agile organization is never ready, never stops learning and never stops adjusting. Do these organizations keep challenging their teams and product managers? Do they adapt their tools and engineering skills to new features and insights? Or have they adopted some practices and do they now keep using these for the next couple of years? A true answer might give the first sparkle to being Agile.

4. One more Agile myth
DILBERT © 2005 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

It is funny how some misinterpretations continue to happen. More productive teams may indeed be one of the results of a good Agile implementation. However, this does not imply that making the transition will get you there right away. No, transitioning to Agile means hard work and dedication. As in all transitions it is about two steps forward and one step back. There is not a general blueprint suitable for all organizations. So come up with a plan, skilled people and a lot of positive energy to start your company’s transformation.

5. Bermuda triangle of Agile
The last cartoon is not an original Dilbert comic but originated from Luca Minudel in 2011: https://www.flickr.com/photos/lucaminudel/6059269914/

Not all experienced project managers or hiring executives truly grasp the notion of Agile. Don’t let them fool you. One-way or the other, you cannot fix all attributes within an Agile project. At least part of the project needs to have a flexible angel, in either time, costs or preferably features. Yes, quality is in most projects not variable. For part of the features that are well understood and technically straightforward, it is okay to go for a fixed setup. Don’t get Bermudad all the way!

Sometimes I wonder if it would be possible to replace expensive managerial courses with just a good selection of these comics and start some honest reflection…..

[edit 2019] See Dilbert still struggles with Agile for new challenges and insights.
Or dive into the evolutiong of DevOps in DevOps: understanding the evolution.

Cheers,
– Sjors Meekels