This week I held a presentation with the title "Professional JavaScript Development: An Introduction for .NET Developers" at the .NET Usergroup Bern (DNUGBE):
According to the organisators the event was a full success and a new record for attendants:
Next week I am going to speak at the .NET Usergroup Bern about "Professional JavaScript Development for .NET Developers".
The event is already almost booked out. You can subscribe for the event on Xing.
This weekend I got my new Mac Book Pro:
I decided to set it up from scratch. This is the software I installed:
Useful System Tools:
Development:
TextMate.app/Contents/Library/QuickLook/ and restarting the Finder.~/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>
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...
I am pe
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...
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
We were used to getting shit done … then they told us about Agile.
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"?:
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":
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:
