Sunday, February 16, 2014

My OSX Tools List for 2014

This weekend I got my new Mac Book Pro:

IMG 1884

I decided to set it up from scratch. This is the software I installed:

Useful System Tools:

 

Development: 

 

Other Software:

*->Installed through App Store

I am grateful for any tips and suggestions:
What did I miss? Where do you know a better option?

Update: TextMate 2 installs its own QuickLook Plugin which I don’t like: I uninstalled it by deleting the Folder TextMate.app/Contents/Library/QuickLook/ and restarting the Finder.

Update: In order to quick look html files as code and not rendered I changed the content of ~/Library/QuickLook/QLColorCode.qlgenerator/Contents/Info.plist and extended the following block:
	<key>LSItemContentTypes</key>
<array>
... <string>public.plain-text</string>
<string>public.html</string>
<string>public.xhtml</string>
</array>

Wednesday, February 12, 2014

Why I don't believe in scaling Agile to the Enterprise

Yesterday I read the post "Approaches how to scale agility" on the Zühlke Blog.

The topic is close to several ramblings I have published recently here on my blog: 

Of course I could not sit still and I posted a sarcastic comment on the post on the Zühlke Blog:

I knew about SAFe, but I am amazed at how many other approaches there are at milking the Agile cow... must be one hell of an udder!

The comment was published (I am a more or less regular commenter on the Zühlke Blog). However this morning the comment was deleted. 

Ok I get it, this is a corporate blog, no place for sarcasm! 

So I tried to formulate a more constructive comment about the topic of "Scaling Agile". It resulted in yet another ranting, which is now waiting moderation… unsure if it will pass the publication requirements (no sarcasm, what about criticism?) I decided that it actually is a post of its own...

 Why I don't believe in scaling Agile to the Enterprise:

I am peScale smallrsonally very sceptical about scaling Agility. Probably because of my understanding of "Agile". I think there is still no common understanding what Agile really means. Since there is no such common understanding, I think Agile is still mainly a marketing term that has probably reached the peak of its hype-curve. On this peak many people try to make money from it, and since money is in the enterprise there are a lot of attempts to marry Agile with the enterprise.

My current understanding of Agile is best described by the "Agile as a Doctrine" by Jason Yip:

1. Reduce the distance between problems and problem-solvers
2. Validate every step
3. Take smaller steps
4. Clean up as you go

Let's take SAFe as an example: Is there a visible attempt at adressing those points? I don't think so...

  • Instead of reducing the distance between problems and problem-solvers we introduce more layers of indirection with several layers of "architects", "product owners" and "customer proxies". We add several layers of processes for roadmaps, plannings and priorizations. We introduce portfolio-, product- and release-management and build up several layers of backlogs. (example)
  • Instead of validating small steps we focus on long-term roadmaps. We increase our effort in crafting complete backlogs. We believe that tracking activities on a micro level will somehow lead us to success.
  • We have a hard time focusing on value, therefore we keep ourselves busy with optimising for productivity.

This is in my opinion a return to the waterfall. Of course, this is not a new insight: According to Forrester Water-Scrum-fall is the reality of Agile today.

Can we change that? I don't think so. I think most smart people understand the concepts of Agile in theory. I also think that most successful people today are applying Agile principles to their everyday work and personal lives.
However I have the feeling that Agile just does not scale well on big projects or on big organisations. The bigger a project/organisation the bigger the need for structure and formalism. At a certain size you need plan driven approaches. Sad as it sounds, trust can't be the main pillar of big organisations / big projects. Therefore people need a plan and the option to blame. And there is the inherent conflict with Agile.

In my opinion Agile works for small, enthusiastic teams where you can base everything on trust. It does not work in corporate environments. Of course there are exceptions (see Github Inc, or Valve ...), but they are really not comparable with typical management driven corporations.

And let's face it: Our management driven economy was very successful in the last decades. Waterfall worked! Plans worked! Management was successful!
Of course recent trends (i.e. trend to more knowledge work) seem to imply a change. Embracing Agility is also a consequence.
But I think the trend results in questioning the reason for the existence of large corporations. Why do we need large corporations in a purely knowledge-based and perfectly networked work environment?
I think that is the ultimate consequence of embracing Agility: Not scaling it to the big corporation, but denying the reason for corporations altogether.
Sadly consultants would not make money with that message...

 

Update (2014-02-16): Thanks to Scott Ocamb for replying to my post here: Scaling Agile - What does this even mean?

Update (2014-02-25): Thanks to Erwin van der Koogh for his highly interesting reply: Scale Agile by Scaling Autonomy

Saturday, February 8, 2014

Not happy with Agile, but why?

We were used to getting shit done … then they told us about Agile.
 

Smiley2

I stated that something went wrong with Agile. This probably boils down to how Agile is applied in the Enterprise. And I am not the only one stating this.

But what went wrong and why? Criticising and pointing out problems is easy. But finding the root cause for being unhappy requires more reflection.

So what does Agile really mean?

We all know the Manifesto for Agile Software Development. But that are some high-level principles that were formulated more than a decade ago.

Software development looked radically different at that time. In the meantime we have gathered about a decade of experience in Agile Software Development and the software development landscape has changed quite a lot. If you believe some studies then Agile is now mainstream and the most widely applied methodology in software development.

Of course the values from the Agile Manifesto are still valid today. They still are the base for an agile mindset. I guess they are commonly accepted today in the industry and hardly anybody will directly disagree with them.

But it became clear that the Agile Manifesto is not enough. Even if we agree with it in principle, do we reflect it in our every-day actions?

Some people tried to go further with more manifestos:

However it became obvious that the manifestos and the reality in the trenches of the enterprise were not congruent:

Today we have at least 12 Agile Methods. But are they any relevant for us as developers?

A lot of times when I speak with other developers, then they say that "Agile" is actually just common sense. A lot of developers claim to have been "doing stuff the agile way" before it was even called "Agile".

So, what does it mean to "do stuff the agile way"?

My favourite interpretation is what Jason Yip calls "Agile as a Doctrine" in his post: What do you mean when you say "Agile"?:

  1. Reduce the distance between problems and problem-solvers
  2. Validate every step
  3. Take smaller steps
  4. Clean up as you go

That is to the point what we developers do when we do Test-Driven-Development. It even does not have to be "pure" TDD: It's the Mindset not the Tool! 
It's also reflected in the basic methods engineers or scientists learn to practice (build up knowledge, take small steps, validate expectations).

Further more it's what most of us practice in some form to manage our personal live. Implicitly with "common sense" or more explicitly with GTD or Personal Kanban: we know that we have a limited amount of time and we (more or less successfully) optimise to get the most value out of it. We do not optimise for productivity, we optimise for value! We can do that, because its our lives.

If we as developers already do "stuff the agile way", where is then the problem in the current state of software development?

Here it comes: The software development industry today is not about the craft of writing software, it is mostly about management! At least in the environments where most of the software developers work.

And that is where Agile is currently failing. Despite the fact that the principle of Plan-Do-Check-Act is taught in most basic management courses, in the enterprise environments I have been involved, things are not done the "agile way":

    • Instead of reducing the distance between problems and problem-solvers we introduce more layers of indirection with several layers of "architects", "product owners" and "customer proxies". We add several layers of processes for roadmaps, plannings and priorizations. We introduce portfolio-, product- and release-management and build up several layers of backlogs. (example)
    • Instead of validating small steps we focus on long-term roadmaps. We increase our effort in crafting complete backlogs. We believe that tracking activities on a micro level will somehow lead us to success.
    • We have a hard time focusing on value, therefore we keep ourselves busy with optimising for productivity.

For developers this environment is especially frustrating, since "doing stuff the agile way" works on the technical level and also on the personal level. It just doesn't work on the management level in typical enterprise environments.

Lately there are fresh movements that try to address the chasm between Agile development and Agile management:

Those movements try to address shortcomings in the current adoption of Agile in the Enterprise. 

But I remain sceptical. Of course we can still go a lot further in adopting Agile on all levels. But I have the feeling that Agile just does not scale well on big projects or on big organisations. The bigger a project/organisation the bigger the need for structure and formalism. And structure and formalism prevents "doing stuff the agile way".

So how can we developers deal with that?

I think as developers we have almost no chance to influence the Agile adoption in the typical enterprise environment: Since it has to happen on management level, once you would be in a position to really have an influence, you are not a developer any more.
But as developers we can choose who we work for. This is especially true with the current shortage of developers in the industry. I am confident that there are environments out there where software development can happen in a more agile way on all levels. I even think that because of current trends in the industry these opportunities will increase in the future. More and more small organisations prove that there is less and less need for big corporations in the IT industry. 

Of course big corporations have their advantages. Security and stability are often among them. So every developer has to decide for himself if "doing stuff the agile way" is really worth it in comparison.

Finally, how do we developers find those jobs? I think it's by really looking at the management of a company. What does management really do? What are the management processes?
Github Inc. is the current poster-child of an Agile company. In a talk about their model of distributed management they summarise my above rantings with this venn diagram:

GithubManagementProblems

Friday, December 13, 2013

Dichotomies in software development: Anti-Anti-If Campaign?

In the team I am currently working, a toy contest is going on among developers to reduce if-statements in the code-base to a minimum.

This goes along with the Anti-IF Campaign: LESS Ifs, MORE POWER:

600794 581837505169922 1396033429 n



On the other side I recently stumbled across the following code examples from current "bleeding-edge" technologies:

Meteor: Hey cool, we can use the same code on the server and the client! We just have to check where we are and then do different things!

(From the official Meteor.js examples)


Appcelerator Titanium: Hey cool, we can use the same code-base for Android and iOS! We just have to check where we are and then do different things!

(From the appcelerator wiki: Supporting Multiple Platforms in a Single Codebase).


That just looks convincing. Next step on this path to enlightenment would probably be to put all the code in the same source file?

Wednesday, December 11, 2013

Presentation: Professional JavaScript Development (An introduction for Java Developers)

250x250xJavaScript logo png pagespeed ic I5rUk2FRl9

This week I was invented again to speak at the SBB Developer Day 2013.

As in the last three years, I enjoyed the event very much, and I hope to be invited again next time.

SBBDevDaySmall

Thursday, November 21, 2013

Software: To eat and get eaten…

FoodChain

It has been declared:

Software is eating the world!

 

But lately it seems like:

Management is eating software development!

(Or at least it's sucking out all the innovation and creativity which used to be a major part in software development)

 

Some public indications of this trend are:


Is this a bad thing or is it just a sign that the software industry is growing up? Does this boil down to the old question whether software development is craftsmanship or manufacturing?


Tuesday, November 12, 2013

Quotes of the Week: Meetings

Meetings are toxic: They usually convey an abysmally small amount of information per minute.
What exactly is wrong with meetings and managers (or M&Ms, as we call them)? Well there is nothing intrinsically wrong with them. What's wrong is how often they're applied in office situations.
If you are in a room with five people for an hour, it's a five-hour meeting.
Meetings procreate: One meeting leads to another meeting leads to another...
By rationing in-person meetings, their stature is elevated to that of a rare treat.
We lead people not machines, we embrace spending more time with our team than in meetings.

Meetings
Meeting

Last but not least: Never forget to run the awesome Meeting-Ticker

Related Posts Plugin for WordPress, Blogger...