From the Agile Transformation Trenches

Thou shalt deliver software early and continuously

The author of the UML tutorial blog has declared that agile is 'the new religion' and that the principles behind the agile manifesto are really The Twelve Commandments of Agile. The blog's author states that he does not necessarily disagree with the principles but believes that agilists treat them as religious dogma. Unfortunately, I think the blog's author is the one who is mistaking principles for dogma.

The first commandment he comments on is the agile principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. The blog's author comments:

Next let us considered if it is practical to make "continuous delivery" to a production environment? Anyone even remotely familiar with enterprise application rollouts will tell you that a production release is a big deal. No company can afford to approach a production release in a cavalier fashion and no IT department of a Fortune 500 company every will. A release every quarter is the highest frequency they will countenance. If I tell them I will make "continuous" releases, well, my consulting days with them will come to a premature end!

As someone who's involved in ensuring the enterprise readiness of Borland's software, this is a topic that's near and dear to me.  Borland's process is: we give our software to customers each sprint for acceptance testing only, which allows our customers to try out the completed functionality and give us feedback quickly. However, we deliver enterprise-ready releases a only few times a year.

When a customer takes a sprint build of our software, they agree to the following condition: the delivered functionality should be functionally complete, but the software has not yet been subjected to full enterprise testing, and it is therefore not ready for and should not be deployed to production systems.

You may infer from the paragraph above that we don't do enterprise testing in an agile fashion--we save it until the end of a release. That's not accurate. Typically, we perform enterprise testing (at most) one sprint behind the sprint in which functionality is delivered. Then at the end of the release, we have a 'release readiness' sprint in which no new functionality is delivered. One purpose of this sprint is to allow the remaining enterprise testing to be completed.

In this way, we feel we uphold the spirit of this agile principle--deliver frequent, incremental progress--in a way that works for the enterprise software that we develop.

The fun and fear of learning on the job!

Welcome to Borland's new blog – a blog that brings together a number of us Borlanders from all different areas to talk about our experiences changing the way that software is delivered and improving the results of what is delivered.

I'm thrilled to be invited to participate and contribute in this blog, yet at the same time quite nervous about it. This is a new venture for me as I typically take talking over writing any day!

My current role in Borland is a Domain Specialist for our Modeling solution but I am now ramping up to be a similar domain expert for our Business Management Suite product which focuses on the process of managing software delivery.  As a Domain Specialist in the Americas, I support the front-line solutions engineers throughout North America, and Latin America.

I originally came to Borland from TogetherSoft, a modeling focused company that Borland acquired in 2003.  Can you tell who the other ex-TogetherSofties are on this blog?

My early interests when I started as a programmer/analyst had to do with analysis, architecture and design patterns.  All three areas helped me understand the business problems I was dealing with, determine how to communicate those to development, and understand what was coming back out.  I'm still very interested in patterns, particularly organizational patterns for transformation and change management, as well as for learning.

Along the way, I was introduced to Extreme Programming.  Did that ever throw me for a loop!  Miroslav, here's how you do OOAD, learn it well .... Miroslav, here's XP, let's challenge everything you know about OOAD! Arrgh! I'm over that now, but did it twist me for a while.  I should point out that this expanding horizon occurred while I was mired in Analysis Paralysis quicksand, and I was doing everything iterative and incremental that I could find to get out of it. Was I ripe for converting or what?

I've been an evangelist for agile approaches to software development ever since.  I was particularly thrilled to participate in some of our customer endeavors where we came in to help them examine, understand, and adopt agile practices.

My goal with postings on this blog will be to cover not only my own journey and conversion to agile, but some of the best practices and advice that I’ve learned along the way working directly with these customers. I look forward to hearing from you to understand some of the questions or "learnings" you might have about your own journey.

That's all for now.

What school are you?

I kicked around several ideas for an introductory post, trying to balance giving some personal background with something of broader interest....Trying to balance answering "Who am I?" for you, without being vain enough for you to instead ask "Who does this guy think he is?"  Asking the question in the title gives me a good balance.

One of the ideas that has really helped me on understanding "Agile Transformations", both in myself and in teams that I see and work with is the concept of "shuhari", which defines the stages of mastering Japanese martial arts.  Shu is the level when you start and are loyal to the "school" you are learning from- you're following the practices by the book.  Ha is when you are understanding more of the principles behind the practices so you can go beyond the practices you learned in your school- how to extend them to situations not originally envisioned or what to do when a practice used to work or what ideas from another school you'd like to mix in.  I get these two, but Ri?  Ri is defined as transcendence when all moves are natural.  I'll let you know if I experience this transcendence!  In my book, it's not too terribly important where you start since people around you will get to the point that they're pulling in ideas from other schools. Or they'll be dogmatically stuck to the starting school and you won't want to hang around them.

So, what "school" are you when it comes to development and how to improve?  For me, I started out seeing many different approaches to doing things better- some measurement driven, some from a maturity model, some from a vendor.   It wasn't until we started using Scrum inside Borland that I saw something that I really believed in - the other results I saw from the others were just too mixed.  Sure, Scrum's results are mixed but the experiences I've seen are much more on the positive side of the ledger.  So, would I say I'm of the Scrum school?  Or even the Schwaber Scrum school since that is the first book I had?  Or the Mike Cohn Scrum school since he was the trainer in my first ScrumMaster training?

Nope.  None of the above.  While appreciating Scrum, serving as a ScrumMaster and seeing the way it benefits teams, I was exploring other areas of the Agile world and finding other approaches that resonate more with me.  I haven't done hardcore XP.  I'd like to say I'm of the Real Options school, but I'm not sure I could pass the entrance exam.  The area that resonates the most for me is Lean, whether described by the Poppendiecks, David Anderson or Corey Ladas and crew.  My personal exploration and experience with these schools of thought will be one of the many areas I cover in this blog.

So I'm interested to know, what school are you?

"You don't have to change. Survival is not compulsory"

In my role as a Director of Product Management at Borland, I have to deal with a lot of change so that quote from W. Edwards Deming really hits home. Let me explain.  

Marketing discovers a new feature that is suddenly a "must have". A customer decides their top 10 defects are no longer as important as their new top 10 list. Senior management acquires a company with an existing product line and needs new integrations. Engineering decides yesterday's technology is passé and wants to start using a new technology. Sales expands to a new country and discovers a new set of localization requirements. Finance wants to cut license costs so they demand removal of all commercial components. And sometimes it is just as much my fault –- I do not always know what I really want until I can see some working software. At times, I just want to say, "Stop!"

Despite my wishes, I know the changes will not stop. Hence, I know from practical experience that change never stops, especially when it comes to requirements. Freezing requirements just means refusing to meet new needs. The success of my products depends on my ability to embrace change. Of course, this is easier said than done in my role as Product Manager.

The truth is that I have been coaching people about embracing change for a long time. In 2001 and 2002, I worked as a Mentor at TogetherSoft where I helped coach customers on adopting Feature Driven Development as a way to deal with change. I was also fortunate to observe some early adoption of Extreme Programming (XP). After Borland acquired TogetherSoft at the end of 2002, I saw more agile practices during customer engagements and started to observe Scrum and XP implemented on a large, enterprise scale. In 2005, I left field consulting behind to join the Borland engineering team as a Product Manager. It is in this role that I have been working as part of a broader Borland initiative to drive Agile practices, such as Scrum, into common use across the organization and my product team specifically.

Having been a part of Borland for nearly 5 years, I have experience in the application of many tools and techniques. I have taken a turn with many different techniques such as business process modeling, use case analysis, OOA/D with UML, and lately user stories and personas. I have also taken a turn with many different types of tools for requirements, modeling, change management, version control, and development. I comfortably consider myself a "tools person". I like using tools and, unlike some folks I have met in the Agile community, I think they play important role in software development -- just not more important than individuals and collaboration.

Through all of these experiences, I know one thing -- for all that experience, I still have a lot to learn. This is why I am so excited to start blogging. I look forward to the sharing of problems encountered and solutions tried. I hope you gentle readers will join me in exploring the challenges of being Agile in the modern business world. Together we just might find the path to survival.

My life as an agilest working in a non-agile world

As my first official post on the Borland blog, I thought it would help to first introduce myself. My name is Beth Williams, and have over ten years experience as an IT consultant, helping a number of companies ranging from British Telecom to Getronics to improve their IT organisations through the adoption of process and tools. In recent years, I’ve worked as both a scrum masterand agile mentor providing guidance on how to apply agile methods in seemingly “non-agile” environments. All this whilst also performing the daily activities of a certified scrum master.

This may sound easy but consider the challenges involved when your scrum team is not collocated or not 100% resourced to the project. How do you plan a sprint and what happens when no-one can physically attend stand-ups? What if your customer insists on a more traditional PM methodology like RUP but your team has been agile for years? How do you bridge the reporting gap?

In this blog, I hope to share my real life experiences of helping organisations transition to agile, the compromises that sometimes need to be made and the “tricks of the trade” that have helped teams become agile in the hardest of circumstances.

The question then becomes why bother going agile if the environment is hostile?

Because it works! It’s the most realistic way of managing the delivery of “anything” that I have ever worked with.  I hope you also notice I’m not limiting this to just software delivery - agile can work for any set of deliverables.  It’s all about knowing when to be pragmatic.

Greetings from an agile tester

Greetings. My name is Stan Taylor, and I'm a quality assurance architect here at Borland. I am honored to have been part of Borland's first agile team and to have been involved in the rollout of the agile methodology here at Borland.  Recently, I've been involved in the effort to implement usage of Borland's BMS products to manage our own software development and delivery business.

I'm having a terrible time writing this introductory post. OK, let me see if I can pinpoint the problem...

I'm a cynic. Everything that I start to write here makes me feel like I'm a cheerleader for Borland. If I were reading it, I'd think it was just marketing babble. But the truth is, Borland's commitment to agile has led to very high job satisfaction for me, and it helped me to tie together a lot of thoughts about process that I've long held.

I started my own agile testing blog earlier this year as a place to work out these thoughts and to get feedback from others. In this blog, I hope to share more of the specific experiences I've had here at Borland that have made me feel so enthusiastic, as well as some of the challenges we've faced and how we've tried to address them.