Enterprise Agility – How far would you go?

One of the sessions in the Agile Coach Camp Canada 2014, in open space format, was on Scaled Agile Framework (SAFe). The session attracted many participants who works in large enterprises. The interesting thing is that rather than talking about the specific implementation and experiences people had with SAFe, the discussion went directly to whether SAFe is agile enough to be called an agile framework. The specific arguments are outside the scope of this blog. The main argument (my interpretation) against it though is that SAFe seems to put an iterative, but somewhat sequential and hierarchical structure around accepted agile methodologies like Scrum and Kanban. The main proponent (my interpretation again) for this framework feels that the current corporate structure and external environmental factors like regulation is a real hard constraint just like any other technical constraint that agilists have to work with. SAFe is a very attractive way of building enterprise agility with what we have. This is very interesting to me as I am currently consulting for a big bank in Canada. Does this provide a structured way to finally bring large enterprises across the chasm over to mainstream agile community?

Incidentally, I got involved in a passionate online debate on LinkedIn group Lean and Agile Software Development – “QA organization with agile teams”. The discussion started with a question on whether you need a QA Director role in an agile software development organization of decent size. The replies converged nicely into a qualified “no”. While the managerial oversight is an overkill, the need of a voice in support of quality and quality practices is there. The need to nurture and care for QA professionals in the team also exists. Whether these responsibilities become job of one or more and whether they have a title of Director are implementation details. However, the discussion spiraled into whether a flat network system is better than hierarchical structure. While no one favours a deep hierarchy, people with senior management responsibilities, myself included, think there is a scalability issue with network systems within enterprises or public companies.   Sooner or later, hierarchy will emerge to manage external interaction and inter-dependencies between networks.

This brings me back to the original discussion on SAFe. If the premise of flat network systems can become a reality than SAFe may not be the most agile framework that can be applied. However, is it possible for an enterprise to undergo such a drastic transformation even if you have years or decades? How far would you go to move your or your large enterprise client’s organization towards that direction?

Alphali Inc

#TDD-is-alive … and well …

I attended the Agile Canada Camp Canada (#ACCCA14) 2014 over the last weekend. It was really invigorating and lively. I was able to pick up several new concept and ideas and helped a few people along the way. I will post some important thoughts in a series of blogs on these topic. This is my first one as it is closely related to my previous post on the outrageous claim by DHH on TDD.

I was actually going to talk about this topic in the Open Space session, but two people already grabbed that spot, so I eagerly joined the conversation. While opinions from both sides were presented, consensus was that TDD is a good coding practice that should not be buried by one hash tag. We all understand where Hansson was coming from and some people even thought Hansson was only referring to rails world and not other languages. Nevertheless, the more important message we want to send though is that TDD is a really useful tool for people starting out with the unit testing and programming in general. It is like a training wheels on a bike. The technique will encourage developers to think about how to design the application in a testable manner which turns out that encourages loose coupling. Over doing it will lead to falls, just like a fast turn on the bike with training wheel will do, but once you have the habit of thinking about coding in this way, then the wheels can come off.

So here is my contribution to this cause. TDD is alive and well, in fact, it is maturing. Like any good idea, challenges to established “truth” are healthy, but present the full picture, not a sensational hash tag (the power and downside of Twitter), so that we don’t mislead people.

power of moderatioin

Does #TDD really need to be dead?

Test Driven Development (TDD) has always been a hard sell in many companies I have worked with. The resistance would come from all possible directions. Developers worry about extra overhead, managers worry about delayed project schedule, and finance worry about increased cost. However, since David Heinemeier Hansson posted his controvertial post “TDD is dead. Long live testing” more than a month ago, an already heated topic just got a lot hotter. For example, it has sparked agile heavyweights Kent Beck, Martin Fowler and David to have a series of hangout sessions to discuss and understand each other’s view. These are great discussions with lots of history and knowledge embedded. I highly encourage everyone to at least read up on the summaries of each discussion whether you agree TDD is dead or not!

Throughout these conversations, I detected a common theme though.  Whether the discussion is around test isolation or design damage; over testing or unit test runtime limit, the objections seem to be derived from observations or experiences of strict, or better dogmatic, execution of a believe. This reminds me how my son would insist something as universal truth because he has seen it once. It is very hard to convince someone otherwise of what they have seen or done. As someone specilized in software development methodologies and best practices, I have learned and still often remind myself the principles of Tai Chi. Water, one of the softest things on earth, will always erode away any type of rock in their way. Anything used in extreme can be harmful, be it a technique, methodology, medicine, or ideology.

This is also why I not only preach agile development, but also try to live an agile life. Life is a journey, we, as driver of our own lives, have to steer us out of trouble in order to reach the next stop. So, can  we declare TDD as dead but still be an advocate for proper testing? Yes. Do we need to declare it as dead in order to make that point? I don’t think so. What’s your thought?

What does the origin of DevOps teach us?

Recently, I read an interesting story on how the name DevOps came about.

http://blog.newrelic.com/2014/05/16/devops-name/?utm_content=5416574&utm_medium=social&utm_source=linkedin

True enough, as an “afanaciado” of DevOps movement, I didn’t know this story. It even had a reference to the city I work in – Toronto. It is home to one of the two people that caused this name to appear! I am feeling proud, now:-) As I read the story, I was intrigued with Patrick Debrois and Andrew Shafer’s tenacity to pursue what they believe is important for two years in the face of seemingly indifference from the fellow community members. In addition, Patrick’s courage to organize the first #DevOps conference in 2009 on a brand new topic further proved that if you believe in something, follow it up with action, then you will be rewarded. That reward may not be success as in this case, but the experience itself will be reward enough.

That is one of the fundamental pillars of agile. Don’t wait for everything to be ready. Don’t expect all the documentations will be complete. Don’t even think you can spec out all the possible edge cases before building the software. Do execute on what you already know. Get feedback quickly and then build on top of that. You will be rewarded with information/knowledge that otherwise will just be a design/estimate/assumption/risk. As an added bonus, you might just get a working product that’s right for the customer. Isn’t that nice 🙂