The more things change…

November 12, 2015

I have often heard it said the more things change the more they stay the same.  While I am sure it is not completely true all of the time, it is interesting how many times our industry regenerates certain concepts, only better and better with each incarnation.  There are many examples of this.  When I started my career, I was responsible for several large mainframe applications for a large oil company.   These were the days before the client server revolution.  At that time, application developers had the luxury of having their application hosted in a single instance.   Their individual users did not deploy any software.  Any time an enhancement or bug fix was deployed, the entire user community could instantly take advantage.

Today, there is a big trend toward SAAS based applications.  This allows applications to have the luxury of having their applications hosted on a single instance where all of their users get the benefit of any deployed bug fixes immediately.  Only this time, the platforms are cloud based, elastic, and can be deployed on virtual systems that allow for low cost scaling to user demands.  It is a very exciting time to be in the field of software development.

As the world was moving to client server in the 1990s and early 2000s, there became a need to transform the way we build software to be much more agile.  At that time, there was a tremendous push toward transforming R&D organizations to be able to deliver software in a more predictable manner with high quality.   As an R&D leader at the time, I was a part of a major Agile transformation.  Today, I am involved in building a SAAS platform for our company.  What is enlightening to me is the demands and pressures for agile delivery have surfaced again.  Only this time, with more rigor and even more focus on continuos delivery.

On a flight from Boston to Houston, after a meeting with several colleagues regarding our SAAS direction, the similarities between what we need to do now and what we needed to do a few years ago gave me cause to take a look back at our first agile transformation and contrast that to the demands of today’s SAAS based development projects.   They are quite similar, only this time around we must be faster, stronger, more disciplined and more agile.

Here is a paper I wrote back then.  The similarities between then and now are intriguing. So much so that I have actually decided to start blogging about Agile software development again.  I hope you enjoy.  Here is the link to the paper…

Managing a Large “Agile” Software Engineering Organization




Question: Statistical Analysis to Predict Outcome of Software Projects

January 16, 2009

Recently, I was wondering if there has been any meaningful work done to apply linear regression analysis to determine the correct balance between various dependent variables used in an Agile process.  For example, what is the impact of architectural runway, number of developers, hours per day, length of an iteration etc. on the quality and output of a software project?   There is no question many ideas and opinions exists on the right value for these variables.  However, I would like to know if there is “statistical proof” on how each of these variables impacts a software project?  If anyone out there has a work they I can reference, I would appreciate it?

Discipline in an Agile Team Reduces Stress

October 23, 2008

Recently, I was reviewing some of the Agile projects in my area.   One of the things I noticed was there is a direct correlation to the discipline a team has managing its day to day activities and the overall stress level of the team.  Agile without discipline is chaos.  This has always been my belief.  However, I believe there are some intangible benefits to being disciplined during requirements definition, release planning, iteration planning, daily standups, demos etc.  This intangible benefit is the teams tend to feel a lot more in control when these items are in order.  For scrum masters, stress is reduced simply because they can speak intelligently about the meaningful functionality that has been completed.  For the team, they are less stressed because they believe they are a part of an organized project that has a clear probability of success.  For management, a team that has the proverbial “stuff” together is a pleasure to work with and the antidote to many other stressors.

Agile Axiom #5 – Understanding and ahdering to iteration acceptance critieria is critical to the overall quality of a release.

July 13, 2008

One of the key benefits of Agile is the reduction in the difference between the level of quality for which we strive and the level of quality we actually achieve. Realizing this benefit requires careful attention to iteration acceptance criteria. Driven by the fact that most Agile methods rely on “inside the iteration” testing as their primary test cycle, the impact of ambiguous or not followed acceptance criteria can have a devastating impact on the quality of a release. Over the past several years, there has been much discussion around what it means to be “releasable” at the end of an iteration. Often, teams will set fairly ambiguous acceptance criteria for marking a story or requirement as complete. The level of discipline here is directly related to the level of quality of a final release. So what is good acceptance criteria? “Good” acceptance criteria needs to meet the following in order to be effective in ensuring a given story or requirement is ready for its consumers.

  1. Can the user or system consumer of a story or requirement complete the task for which the story is to enable? In other words, does it work? This is fairly binary criteria. If the user or consumer can complete the action, then this one is passed. One should keep in mind that if the result of a given story or requirement cannot be measured with this binary view, the story itself may need revision. “Testability” is one of the key characteristics of a “good” requirement.
  2. Are the scalability aspects of the story defined and met? This point is likely the most critical and least understood. An example of a scalability aspect of a requirement might be the number of objects a given UI needs to be able to manipulate. Scalability is often a separate consideration than “inside the iteration” testing usually provides. One could argue whether or not it should be (a good topic for another post). However, regardless of how the overall scalability of a release is managed and tested, it is critical that the scalability needs are considered at design and construction time, within the iteration. Therefore, the acceptance criteria needs to include the scale levels for which a given story must operate. Without an understanding of the scalability requirements of a given story, there is significant risk of needing to rework code after the end of an iteration.
  3. Are the non-functional requirements for a given story met? Other non-functional requirements include but are not limited to platform support (operating systems etc.), foreign language support, coexistence requirements, compatibility and interaction with third-party software, etc. Understanding how each of these impact a given story and to what level they need to be tested within an iteration will improve the overall quality of the release.
  4. Does the story meet the overall quality objectives of a release? This is more of a general criteria but must be examined. It is possible to be build the code to support a story that passes the criteria above but still causes the product quality to be poor. Lets take a simple example. If there is a story that says “Create a file selection dialog which allows a user to select which files to open for editing”. It could be the dialog exists, works with lots of files, and meets the defined non-functional requirements but does not function properly when the user presses the cancel button. Maybe the user sees a stack trace when pressing cancel. This case may not be captured as a specific acceptance criterion. However, it will likely need to be addressed (or should be). I would suggest there is an ambiguous criterion which requires that products must be at a “reasonable” level of quality beyond the defined acceptance criteria. This notion does not imply a level of quality less than the traditional criteria states, it implies the quality criteria will likely not cover all of the cases which should be tested. Agile helps with this situation as the product is being tested as it is being coded and these issues will be addressed within an iteration before the code is committed or causes other problems. In waterfall methods, these issues would be found much later in the process and would certainly be much more costly to address. In either case, success with this ambiguous level of quality requires a team that establishes a high threshold for quality and simply refuses to deliver code which does not meet the basic quality objectives of a given release.

When teams transition to Agile, the lack of a full testing cycle at the end of the release creates a substantial risk to the overall quality of a release unless the stories and features are tested at the end of the iteration. This is done through the proper defining and testing of acceptance criteria for the stories and requirements that are marked complete for a given iteration. Additionally, stories and features should be at a level of quality which meet the objectives for a given release. For highly successful Agile teams looking to evolve into test driven development, the need and ability to define of detailed acceptance criteria “the tests” is a prerequisite.

Is it possible to be half Agile?

July 5, 2008

With the all the hype in recent years regarding Agile software development, one does not have to look very far to find a team or organization claiming to be Agile when in fact their methodology is anything but Agile. Recently, I was discussing this phenomenon with a colleague. The conversation focused how Agile should be defined. What is the true test as to whether or not an engineering team is Agile? What does it mean to be Agile? I thought I would take a few minutes and share with you what it means to me.

There are many Agile-like characteristics which can be evaluated as to a team’s level of agility. However, I believe there are three key principles that must exist in order for a team to be Agile.

When your Agile project starts have you committed to a fixed set of features using a fixed set of resources to be completed on a fixed date? If the answer to this is “Yes”, then it is impossible to be Agile when making changes to the project scope to ensure a high-quality on time release. Sure to be controversial, it is my belief that projects with these three variables fixed simply cannot be Agile.

Does your project include a series of increments or iterations that require the completion of “releasable” or “working” software” (defined, developed, and tested) at the end of each increment? Completing working software in an incremental approach enables the team to re-evaluate the project scope at the end of each iteration. This is the foundation for having the ability to make decisions at the end of each iteration. If none of the features are complete and tested until the end of the project, it is too late to re-asses and ensure an on-time successful release.

Does your project allow for the team members to operate in an empowered fashion in which each team member has some ability to influence the methodology and engineering practices? One of the key principles in Agile is believing the people who manage and build the project day to day know the most about the changes that need to be made. If the team does not have the empowerment to self-adjust then there is no mechanism to be Agile.

While it is true most Agile methodologies call for much more than these three items, these represent (in my opinion) the foundation for operating in an Agile way. Adherence, to these key principles as one transitions to Agile is critical to the long term success of the transformation. In short, “Variability”, “Incremental Completion”, and “Empowerment” are the most critical Agile characteristics. All other Agile concepts support at least one of these. For example, automated testing enables incrementally releasable software.

So, is it possible to be half-Agile? It may very well be. However, projects not containing the three principles above will struggle to be successful with their transformation to this new and exciting methodology.

Agile Axiom #4 – To be successful with Agile, failure is more than an option, its necessary.

April 8, 2008

I am sure most of you have heard the movie quote “Failure is not an option”. You may have even used it as a motivational technique. With Agile development, I would suggest this statement be modified. It works best like this “Failure from time to time is expected – trying, assessing, and adjusting are not optional“.

Most Agile methodologies call for some type of ongoing assessment of the development process. The assessment is intended to produce explicit process changes that are applied to the next iteration or release. Many Agile teams struggle with this in the beginning – particularly when their roots lie in a traditional waterfall management structure. However, it is one of the most important concepts with “Agile”. It is critical that teams be allowed to fail in the process, bring creative ideas to address problems, and determine how improvements are made. There are two primary reasons for this.

  • The individuals actually working the process are likely to have the best sense of where the problems are and how to address them.
  • People who have influence over how they work are typically more satisfied than those who have a process forced upon them and will demonstrate more passion. This results in an improvement in quality and productivity.

On one of my first Agile projects, the team was struggling with the acceptance rate of their stories at the end of each iteration. For us traditional managers this was of significant concern. It seemed that no matter what we told the team to do, things would not get better. The management team tried measuring the work completed and determine where things were breaking down. This resulted in great debate over the metrics – thats about it.

We even would drive the retrospectives from the management level. If you want to call them retrospectives – these meetings were more like managers listing out what the scrum teams needed to change. Somewhere along the way, we shifted our thinking (with a little influence from Agile thought leaders) to a mindset that allowed us to emphasize the importance of completing and accepting the stories to the teams and then empower them to make adjustments. As managers, we needed to back off and let the teams work the Agile process. The only management directive was that the retrospectives will occur.

Slowly the teams started to increase their story acceptance rate. Each iteration they would make small adjustments to the process. Some would change their iteration plan to accurately reflect the velocity they were able to contribute. Some improved their testing processes to have the Quality Assurance engineer working side by side with developers. The average acceptance rate improved by over 25%.

The challenge with empowering teams to this level is to find the right amount of influence each independent team has on their processes. For example, if there are five teams contributing to a major release of a single product, it would not make sense to allow each team to define its own iteration length. Its important that managers develop a “feel” for how much to control. Managers will likely find themselves in a similar try, assess, and adjust cycle for the how much control they exert over the teams.

My belief is most managers error on the “heavy management” side in the beginning. It is not until they truly understand what is meant by “People over Process” that they begin to see productivity gains on a large level.

Agile Axiom #3 – An automated build system is critical to the success of most Agile software projects.

March 30, 2008

Recently, I was having a discussion about automated build systems with a colleague. Primarily, we were talking about how important they are for Agile projects. As most of us have, I have witnessed varying levels of usage when it comes to automated build processes.

Looking at the software projects I have been involved with one message is clear…. the better and more frequent run the automated build system the higher the quality in the delivered product. Additionally, the risk is a signficantly lower as well.

In this discussion, I will not get into the specifics of a particular automated build system. I will focus on the reasons to have one.

An automated build system, gives the team a consistent daily goal – complete the work you agreed to do in your daily stand-up, get it unit tested with the testers by your side, commit the code, and make sure it does not break the team’s daily build. Perhaps, this does not need to happen every single day, but certainly many times per iteration.

Each engineer typically works on their parts of the product independently. This is almost always done in their own version of the checked out code. Since each engineer does not test the entire product every day. There is a certain amount of work that must be done when integrating the code. The smaller the amount of code to integrate into the main source tree, the easier it is. Its kind of like when you write a few hundred lines of code without compiling and you are presented with thousands of errors with the first compile. Just as compiling more frequently helps developers pinpoint problems faster, building the entire product helps the teams solve problems faster.

One of the most risky and painful parts of a waterfall project is that time when the code is all written, management has been told the code is 90% done (been that way for weeks), the only thing left to do is pull the pieces together and get the product into QA. However, when all of the individual code pieces are integrated together, a severe problem requiring weeks of refactoring is discovered. At this point, both the date and quality have been compromised. It is very difficult to achieve the true benefits of Agile if this same challenge occurs. Code integration must be frequent.

Recently, I heard of a situation where one of the teams was “accepting/completing” stories that were build on developer machines. The problem with this is the code that is “accepted” may not function the same way when combined with the code from other developers’ machines. The risks here are two-fold. First, teams could find themselves slipping dates as they are going through hardening or even worse having “dead on arrival” defects actually reach their consumers.

To me the best possible situation is to have a nightly build system that does the following:

  1. Builds all the target images automatically
  2. Creates an installable image
  3. Runs and automated installation
  4. Automatically conducts some basic tests
  5. Notifies the “entire” team if a problem occurs anywhere along the way.

As I write this, it occurs to me I could go on for days about the benefits of having an automated daily build system. However, I believe the point is made here. If you have an Agile project (actually any software project) and are not integrating and building your code every day, I recommend you do so. I was in charge of one project where when we added automated nightly processes, the change in team mindset and quality of committed code was earth shattering.

One closing comment on “build engineers”. Find a good one. Often times teams will assign members with less experience to be the “build engineers”. Having a solid build process is critical to the success of your project and should be staffed with the appropriate capabilities.