Category: process

The “A” Word

mikeluntLeave a comment

I’m often amused when someone says something is “Agile” in the software business. While I’m no expert, if there is such a person, it’s always interesting to see how almost any process can be classified as Agile regardless of how much water you can hear falling in the background. For instance, I recently heard of a new so-called-Agile approach that involved filling out a Word document to propose certain defects be fixed in the product as it neared the end of the release. It was justified the new approach (1) created a new process on the fly to allow change in the product and (2) was promoting change by allowing team members to submit change proposals. On the surface, it seems harmless enough, but for those that can’t read between the lines, this process ultimately creates a nonessential accountability hurdle which will make change much more difficult by requiring a form document.

So, begs the question, when is an appropriate time to throw out the “A” word as justification for a change in process? I would argue it should only be used when the proposed change meets the four tenets of the Agile Manifesto. Unfortunately, this seems like a cliche and/or and easy copout, so how about a few of simple guidelines that might trigger one to double-check the Manifesto. (I would argue these guidelines might be a good test prior to implementing any process in any business, but that off-the-cuff suggestion might be a tad haughty.)

Does the new process:

1) Increase the amount of time needed to make a decision by creating throwaway artifacts?
2) Primarily exist to make someone or some group accountable in the face of failure?
3) Attempt to minimize the amount of live interaction needed between one or more groups?

If you answered “yes” to any of these questions, it might be a good time to reflect on the change and reconsider the assumption of Agility.

When insiders become outsiders

mikeluntLeave a comment

As follow-up to a previous post, I wanted to share a recent experience related to having someone from outside the group come in and suggest new ideas. In this case, the outsider was myself, and I was representing the Agilist in a group that was just getting off the ground with Agile software practices. The first few things I noticed were: (1) how willing everyone was listen to my suggestions (as an unbiased outsider), (2) how much experience I had gained within my own group and (3) who the internal champion was and how he was working to transition the group.

 

This arrangement is an alternative to the more expensive approach of bringing consultants from outside the company; however, the obvious catch is the company has to be large enough to have experts from outside the group. The key to making this work is to ensure the experts from within the company remain neutral to any factions that may exist. This is easier said than done, as it quickly becomes obvious where the obstacles are. In addition, the experts should use in moderation specific examples of how they have succeeded with their own group as this may unintentionally arouse feelings of bias. In other words, the internal experts should not continually use “our product x is wildly successful doing blah process”. Instead, they should focus the advice towards helping the new group and showing the benefits the change will make. In general, the experience has made me much more attentive to looking for others who may have useful knowledge from within our organization.

Outsiders

mikelunt4 Comments

If progressive process change is getting bogged down in an organization, one of the remedies to consider is bringing in outsiders. Most likely, these people from outside the company are either contractors or some other sort of consultants in a particular area. Another approach could be bringing in a new manager or other expert into the company as a full time employee. It’s amazing to see how people within the organization will accept the advice of a new voice, even if the message is exactly the same as a previous champion of the change from within the company. (I could write a novel about the reasoning for this, but I’m sure every dear reader has their own story to relate.)

Companies that create an environment of continually promoting change have less of a need for these outsiders; however, it’s sometimes difficult to determine that healthy new ideas are not being promoted when observing from the inside. The key to getting outsiders into the organization is to justify the ROI because of the expense that’s often required; however, in some cases, consultants will perform some free sampler training or consulting in order to get more business if the ideas are accepted.

Counting software defects

mikelunt3 Comments

For waterfall projects, the classic defect curve is used to determine when a product is ready to ship. This is because most of the features have been “completed” during the first part of the development cycle, and the only work left to do is fixing the remaining defects. With Agile, there is a different approach where the work for the next iteration (2-4 weeks) is determined at the beginning of each iteration. This work should include taking the highest priority items from the backlog and working on those. In an idea environment, any defects are including the backlog and prioritized along with all of the features or enhancements to complete. However, when the defects are separated, the counts take on a life of their own.

These counts create perception issues and also cripple the Agile process because they are not prioritized with all the other work that is needed for the product. For instance, ten defects may cause one engineer to cringe, while a customer may not care about one thousand defects as long as the software performs its job. In addition, these defect lists have to continually be reviewed as a separate work set, which makes overall prioritization nearly impossible. In general, separating the software defects from the rest of the work is a relic of the waterfall days, while the Agile way is an all-encompassing backlog. When looking at a defect chart and waiting for the slope to point downwards, a good question to ask is “Why am I looking at a defect chart?”.

Test first software development

mikeluntLeave a comment

Having personally developed lots of software as well as worked with many software developers over the years, I’ve formulated a theory on why lots of developers are resistant to unit testing and test driven development (TDD). The theory is simply that most developers know that 90% (or more) of the lines of code they write are defect free; consequently, forcing 100% of the code to have tests seems counterproductive to many of them. It’s a theory that seems obvious after being said out loud, but I rarely hear it explicitly verbalized in discussions to increase testing.

The mental hurdle that is difficult to overcome is that the 5-10% of the code with defects is like a minefield scattered throughout the product. Many Agile software processes promote a test first then code approach, and this considered a mythical utopia by most software shops. Even though more companies are adopting test first strategies, the key to changing the mindset has to occur in technical textbooks and classrooms. After the ‘hello’ program has been taught, all other examples should start with a test and proceed from there.

Agile processes and life

mikeluntLeave a comment

At last year’s Agile conference, I was entertained to hear one of the group discussions involve ‘relating Agile software development to every day situations in life’. I didn’t attend this group discussion, but there have been many times over the past year where I have taken a mental note of some similarities. While this will surprise very few people, since our work processes often stem from actions outside of work and vice versa, some of the similarities help explain why Agile works in developing ‘craft-like’ products, such as software. I’ve listed a couple of incredibly simple ones, but there are many more.

Paying bills. As any financial planner will advise, a wise person should pay their utilities and other necessities before buying that new ceramic unicorn for the collection. With an Agile process, the truly important features are added first, and once these features have been added, the extras are worked into the product. In the end, there’s little chance of the electricity being turned off!

The big spelling test. When I was in 5th grade, I aced a ~70 word vocabulary test that we were given a couple of weeks to prepare. I’m no word buff, but when the teacher asked me to explain to the class how I did it, I said I had casually studied 5 new words every day for the past couple of weeks. I hadn’t tried to learn the whole list all at once nor cram a few days before the test. This is very similar to the iterative approach prescribed by Scrum and other Agile methods. Break the work out into discrete blocks and concentrate on those blocks for short periods of time.

The point is not to trivialize Agile processes in general, but it is important to note the methods used in Agile are also methods that generate higher success rates in other practical areas.