Tag Archives: SCRUM

Physics of Being Agile

Recently, with all those vibes about SCRUM going around in our organization, a couple of colleagues went for “Certified SCRUM Master” training, incidentally same person trained myself and one other colleague 6 months ago. I got a chance to talk to him over phone and was glad to accept his offer to be a guest speaker in his session. It was difficult to find what to talk, what was expected from me was to share how we are implementing it and our journey with SCRUM. However, understanding the nature of the training environment it was pretty clear for me to send a message to the audience, I just wanted to talk about what can be the real world implementation issues one can have with SCRUM or any other AGILE practise implementation in a place where such concepts are not known.

Jim Collins in his book “Good To Great” started off to explain what is the Physics of going from Good to Great. While trying to understand what he means I started to think Agile as Physics albeit Modern Physics. Why??. Because Classical Physics is governed by Laws, the very nature of Laws is their rigidity. And rigidity is something which is quite alien to Agile. In fact Agile Manifesto itself talks about Principles, which are not that rigid in nature. Try comparing this with Principles in Modern Physics, like the Heisenberg Principle of Uncertainty. Just like how we cannot determine the position and momentum of a particle simultaneously, I see some very similar striking similarities in software.

So what is uncertainty in software, we cannot easily and simultaneously predict the direction of the software and the time when that can be achieved. This very nature of software makes it more an Empirical Approach, rather than a Predictive Approach.

Next came, a statement which is quite close to my heart, this helps me measure the direction in which I am heading. Remember the book “The Goal” I talked about in my previous post. How about little Physics against your Goals? Smile

“Any action which is taking you towards your Goal is productive.“

“Any action which is taking you away from your Goal is counter-productive.“

What is our goal here? Our goal here is to be “Agile” so we measure our actions with the Agile manifesto’s principles, this helps us in understanding the Philosophy of Being Agile.

The last point(s) I talked about was the real challenges we face in our day to day implementation of SCRUM. Initially when I heard that it is not easy I was not believing it. But when we saw that it is hurting us back then I realised the challenges.

As an advocator of Agile practises you might face several of challenges, but I can make out only two :

  • People: It is hard to explain people the philosophy of Being Agile until they see it practically happening.  To make it happen you need like-minded people who should be willing to
    • Experiment, learn and experiment without fear of failing.
    • Fight for the cause, be in regular confrontation mode for the common goal.
    • Sacrifice their mediocrity for a greater good.
  • Organizational: Sometimes it is difficult to implement Agile because the scale in which the organizations want to implement it. That’s if they like it they want to implement it as a big-bang. But that’s not how you can implement Agile practises. These principles needs to be infused, SLOWLY….take small steps and show visible improvements.
      • Sometimes there are financial implications
      • Sometimes there are people waiting for decisions from top management
      • Sometimes there are timing issues, example you are already in between of a release, obviously you wont try your hands on new stuff which can jeopardise your current schedule.
      • Sometimes there are simply lack of proper engineering practises to deal with the shorter iteration philosophy of being agile.
      • and many many more..

I believe somewhere there are solutions, being with thinkers and innovators can definitely help in this case.

The marriage of Microsoft Team Foundation Server and Microsoft Dynamics NAV

I think the time is there to share the core concept of this blog. Like mentioned in earlier posts the goal of this blog is to  inspire Microsoft Dynamics NAV professionals to adopt Agile in their development processes. Agile is a popular topic these days. Most information, however, is focused on other platforms, like .Net development. We noticed there is still a gap between those platforms and Microsoft Dynamics NAV. That is the goal of this blog in a nutshell.

As you may expect from good software developers we have an architecture for the articles posted on this blog. We are very much in favor of eating our own dog food which means we use real  examples with live code. In previous posts you probably saw some screenshots of Team Foundation Server provided Microsoft Dynamics NAV artifacts. The time has come to share this architecture with you.

The concept is simple: we want to apply the standard process template for MSF for Agile Software Development v5.0  to our organization. This template has been created by seasoned  experts and its current version is 5.0. One of the authors of this template (Jeff Sutherland) wrote an excellent article about the details of Agile Principles and Values. What if we try to apply these principles on our Microsoft Dynamics NAV domain? Obviously we want to achieve the same goals, even though we have different tools.

So far so good but we have our Microsoft Dynamics NAV Development Environment with its whims. How realistic is it to apply these principles on Microsoft Dynamics NAV? This question has been on our mind for a while. After researching and discussions we ended up with the following solution: we follow the standard Agile template  and adapt it with Microsoft Dynamics NAV by using the extensions of Team Foundation Server. This effectively means we adapted Team Explorer and Team Foundation Build System with Microsoft Dynamics NAV. As a result we are able to unleash the full power of Team Foundation Server, without requiring any customization of the process or Microsoft Dynamics NAV.

Because of this concept we are able to have one process for both .Net and NAV and AX development. Which is no luxury these days since more and more Microsoft Dynamics NAV solutions depend on .Net components.

I hope I did not scare you by sharing this concept. Remember it took us two years to implement this. The organizational change is the most difficult one. Agile is not the magic word which solves all issues but it surely identifies them. Another  good aspects of agile is that you can take small steps to improve. That is exactly what we did: we started with version control, then build management and after that we implemented scrum. Recently we integrated the Microsoft Dynamics NAV builds with Microsoft Dynamics NAV Testability Framework. Yes we are in the process of continuous improvement right now. In fact, it only just begun :).

Something about SCRUM

There are a lot of reference material about SCRUM available online. To start with you can read the following lists:


Succeeding with Agile – Mike Cohn’s Blog

SCRUM Primer

SCRUM is a flavor of  AGILE. To know the philosophy of AGILE please see the Agile manifesto.

In my opinion  SCRUM simply is a way of doing work. People do have a lot of misconceptions when we  talk about SCRUM, they think it is a way to solve the problems. But I see it differently, SCRUM will not solve our day-to-day problems, it will just help them to be visible. What we do with our problems is definitely in our hands.

When both of us started on this project, we incidentally were reading a book “The Goal: A Process of Ongoing Improvement ” by Dr. Eliyahu M Goldratt. This book was a point of inflection for both of us, as we were trying to correlate the idea to find bottlenecks in our development process and to some extent how we manage things at our company. Even after 2 years of development we still correlate the incidents of the book and try to solve them.

“The Goal”, explains the “Bottlenecks” (constraints) in manufacturing process, we stuck an analogy of this with our development process we follow. I would recommend this book for anybody who is serious in implementing agile. It is important to note that it is “Critical Thinking and Constant Actions” which can help a system to improve and deliver better results.