you are here: Home Home Agile

What if we are doing it wrong?  What if the way we approach building products in software is just wrong?

This is not a posting about estimates or SCRUMbut or anything like that.  This post is is a postulate on what limits we might be implying.  Consider the following:!StumbleUpon!

The one on the right is actually Steve.  Lee wasn't available for the picture as he was cutting hairIn the Agile world (or any responsible product development environment), people don't just talk about high quality, they are passionate about it.  Think beyond software...companies build marketing strategies around quality.  Fruit of the Loom, Zenith, Toyota...all have marketed solely around quality.  But for far too long, software development in general has treated testing as a second class citizen.  Have you seen any of the following scenarios?

  1. Organizational view that 'anyone can test' - evident by 'power users' becoming testing leads without any software background
  2. Team growth due to a high amount of product maintenance / support
  3. View on testing, sometimes from director of quality, that testers should just be given finalized specifications and file defects (and track) against every bullet point

If you have witnessed any of the above scenarios, then you have seen firsthand a testing environment in a sad state.  I can't wave the magic Agile wand and change the world - I think you need a couple hundred kids holding hands and drinking Coke to change that.  I will, however, give some ideas on how we can start righting this ship.!StumbleUpon!

Constant focus on quality and code health is critical for the long term viability and maintainability of software.  This focus on quality is a trademark of agile teams but you don't have to be 'doing the Agile' to focus on quality. Regardless of how you develop software, testing and in particular unit testing are an important tool to have in your toolbox.  Given the importance of unit level testing, why do so many companies struggle with unit testing and its adoption? When unit level testing is non-existent or inconsistent, the reasons fall into two main categories:

  • General misunderstanding on what a unit test provides
  • Developers aren't good / shy away from testing as it is out of their comfort zone

There is a third reason, more like a myth, that is very popular - the myth that 'we don't have time to test'.  This is false - nothing will slow you down more than writing as much code as you can without some way of constantly being able to verify you haven't broken your assumptions of the intent of the code.  We tend to hear this myth coming mostly from developers.  This comment is usually rooted in a blend of the two primary reasons with the majority of the cause coming from developers simply shying away from testing.!StumbleUpon!

Agile practices may seem easier for small, isolated teams but what happens in the real world when applications go across teams and dependencies rear their ugly head?  The answer I hear too often is 'adjust in your planning sessions so that the dependencies go away.'  That's not a real, complete solution to me.  Here is why - that answer makes sense if we are creating an application and we have two stories - Add item to shopping cart and Remove item from shopping cart for example.  In this case its logical to plan accordingly.  We wouldn't want to release the product without being able to add items and additionally this functionality seems in control by the team.

What about this more common example though - a front end team develops an application that depends on data from a data team.  On top of that, not only does the front end team depend on the data team, but so do 3 other teams, all with different priorities and needs.  And since it is the real world, we have a deadline to hit - the application needs to launch in 6 weeks and the data team won't be able to finalize the data for the front end team for 4 weeks.  It doesn't make sense for the front end team to not work, especially if the amount of time they need is greater than the remaining two weeks.  What do you do?!StumbleUpon!

You're going Agile and you couldn't be more excited.  You've read about all of the benefits and want that for your organization and you want it now.  Slow it down a little bit Buddy; realize that not only will Agile change the way you work, it will possibly require organizational and cultural changes.  Your organization only has a certain amount of change it can consume successfully in any given period - you only have so much transitional velocity.

One of my partners in crime at VersionOne, Mike DePaoli, has started a series of posts regarding using Agile to scale Agile.  I couldn't agree more with the thread and chatted with Mike briefly about adding a topic I spoke about at Agilepalooza - the idea of transitional velocity.  We know what velocity is in terms of Agile - the rate at which a team is delivering value, usually measured in average points per sprint or iteration.  Transitional velocity is how much change we can successfully introduce and make sustainable in a given timeframe.!StumbleUpon!

Finding the right amount of detail and decomposition with stories takes agile teams a few iterations, possibly releases, to get comfortable with.  It is a tough balance - we want the stories to be large enoughBut is it Jeff Patton? that our product owner(s) understands what the story is for and the team understands the story contextually, yet we need the work small enough so that we can have confidence in estimating and so that we can get the story flowing through our feedback loop soon.  I want to outline briefly how I like to approach this in the hope that it may help some others.

Jeff Patton is one of my favorite people, an overall awesome dude, and his storymapping is such a beautiful tool that I wish more tools would naturally support it.  When I am working with companies, I use storymapping as means of helping people not only visualize their product but also as means of helping groups understand where and when to break down work.  If you haven't heard or used storymapping before, please do check out Jeff's blog posting on it.  Its ok, I will wait.!StumbleUpon!

Its a little known fact that google was built by 3 staplers, a set of paperclips, and a couple of 2 by 4s.  Yep, some smart dude with a great idea had someone look at his product and that person replied, 'We can do this.  We just need about 4 dev resources and a few qa resources.'The stapler is off to the side

As ridiculous as this sounds, we still see it regularly in software development.  Not only is it amazingly demeaning to call people 'resources,' it also leads to other fallacies, such as:!StumbleUpon!

One of the most potentially dangerous states for a company to be in is where it is successful in spite of itself.  Companies that are (or once were) monopolies have a surplus of cash and little to no competition.  There is arguably little reason for them to change.  Is it possible for a company in this position to care enough about efficiency to adopt agile practices?  Historical success can cause a fear of change - if we try something else we might fail and we are fine now. Not only is this avoidance of change unhealthy culturally, the inability to seek improvement will eventually lead to drop in market position of the company. 

The past few years have seen the adoption of Agile practices in larger and larger organizations.  At last years Agile conference, Alistair Cockburn presented a keynote around the growth and spread of Agile.  One of the cornerstones of adoption is a healthy and desired feedback loop.  What can we do at organizations where competition isn't an immediate concern?  How can you address a space with a low appetite for change?  Is change possible without motivation?

We live in a time where not only can success happen quickly, but failure can happen even quicker. Beyond that, failure can happen cheaply. That fact should be a concern to market-leading organizations and  a prime motivator.  Cheap failure is equivalent to efficient, fast learning.  Your organization might be enjoying a comfortable revenue position now, and perhaps the cost of entry to your market is high - but the idea / company that becomes your largest challenger does not need to come at you from a replacement angle.  The company that challenges a financial exchange does not have to offer all of the same trading properties or strategies.  The challenger to an online auction site might not even come from commerce but from a communication channel that then makes transactions simpler and in more confidence.

Can change happen without motivation?  No. If you are having difficulty finding motivation, then look no further than the startups of the past few years along with the current boom of startups happening now.  The best of these startups are learning all market aspects very cheaply and adapting quickly.   Let this start your motivation for seeking continuous improvement and never being satisfied.  If this doesn't motivate you - just wait... someone with less to lose will help motivate you by making you lose a whole lot more.!StumbleUpon!

I've said it myself before - this software needs to be designed properly; You know, foundation of a house, and such.  Once the design is solid, oh just trust me, we will create some software real fast.  And then we went off to ponder and pontificate, and create documents showing how elegant this solution would be.  We used and diagrammed all of the proper patterns, creating interfaces and abstractions along the way.

We wrote code; tons of code.  We deviated as we learned more of the system, as time became tighter, and so on.  Once the project was released, 'Someone should really update that design document'...and no one does.

Its common, it happens.  I've done it.  But this isn't about the benefits of emergent design, lets look at the common idiom of our software being a house.

Would you want the real version of the house based on the software you build?  Would you want your contractor to agree to a set of prints up front, but once you move in realize that the only way to turn on the lights was to flush the toilet?  How about that study you wanted?  Would you be happy if your carpenter decided that you, 'the user', wouldn't need a study?  Would you feel better if afterwards, the architect came back and updated your blueprints?

4,192,876,492 - that is my estimate of the number of unneeded interfaces in code out in the wild right now.  Would you want that many light switches in your house, you know, in case you wanted to switch something else on besides the ceiling light?

Houses can have blueprints because they are based upon static principles with high commit costs.  A foundation is made of concrete.  You can change it but it will cost substantially and can create structural risk.  Software is malleable and code is not concrete.  We should be exploiting that benefit instead of trying to move towards a less flexible model.

Lets take this a step further.  Houses are built upon civil engineering principles - stress loads of materials, heat dispersion, pressurized values of systems.  For example, the beams supporting your walls are probably slightly over 14 inches apart.   That is not because that was a good number to go with.  That is because we know, through testing, that the stress load we can expect a wall 2 by 4 to support is actually 24 inches on center but because of the varying in woods (drying, species), most carpenters build at 16 inches on center.

What would be similar in concept to this?  Programming languages, platforms, maybe containers or frameworks.  We know how languages function in certain applications and situations; what platforms work best for certain targets; what containers will provide for us.  Even these can be changed - swapping containers shouldn't be painful.  These items are addressable upfront.

Finally, have you ever heard of a civil engineer say 'concrete isn't good enough for this common residential house, I am going to invent something new.'?  You don't, it would be ridiculous, overly costly, and people could die.  But in software, too often we design and say something similarly absurd. 'We need a custom web server, Apache wouldn't scale for our special problem'.  That statement is as ridiculous as trying to make your own concrete.


Some people much wiser than me have made comments such as 'The cost of version 3 of software is exponentially greater than version 2' and '

Think about that.  We may never see a 'version 3' of ebay or amazon. And maybe we don't need to.  The cost of such an endeavor, to replicate what those applications are providing, would not be trivial and the return on such an investment may very well never be realized. 

In enterprise software development, we see plenty of high version numbers.  Some of this is valid - we learn more about our customers and we create solutions to help solve their problems.  If we can say 'Here is how this functionality helps save me time / solve a problem' - then the software could be worth writing.  If instead it is 'It would be cool if the software did this' or the famous 'we need to re-architect the solution' - then we should take a hard look in the mirror.  How many applications out there have some AJAX functionality just for the glamor of it?

Software development is a sunk cost.  Understand that and accept it.  While I am not trying to put people out of work, understand that at some point your software is as complete as it needs to be.  Instead of allowing people to work collaboratively on solving the next problem, too often we create work to keep people employed (more to come on 'Resource Planning').  The changes requested for this software don't create any large tangible benefits, but it will keep the delivery team busy for a few months.  Its ok to not have delivery teams trying to deliver all the time.  Its actually probably cheaper.

Please don't focus on keeping people busy to keep them busy.  Instead focus on having your teams research and understand what your consumer wants and deliver upon that. Not only will you end up with a better offering and a competitive advantage, you will find that you now have a staff of highly engaged people solving problems and not just going through the motions.!StumbleUpon!

To the contrary of my previous post, I thought I would say what we do know. Without further ado, What we do know (an abbreviated list...well, hopefully)

  • We know that its hard to keep an architecture simple
  • We know that if you have a solution or tool in place that has a 'large impact for replacement' - boy oh boy, did you either eff up the use of the tool or did you purchase one sh1tburger of a tool to start with
  • We know that if you want your employees / team / co-workers to be engaged and highly productive, you have to allow them to be engaged and highly productive.

Perhaps I will dive into this in more detail in future posts.!StumbleUpon!

You know those conversations you have in your head that always come across sounding so awesome? Well, here is the start of one that I had in my head a few months back, and a conversation that I wanted to have but you know, at the time it might have been career limiting.

Command-and-control-director: 'You don't know my world. I've worked for 10 years to make my world just right, you can't change it. You don't know the implications of the changes you are suggesting and how it would impact the company.'

Me: 'You're absolutely right. I have no idea of the implications. And on top of that, I have no desire to know or even hear the implications.'

By no means do I claim that this is an original thought - sometimes it is prior knowledge that blinds us from seeing and understanding other opportunities. Once my daughter wanted to take off her shoes and socks and go stand on some wet rocks in this rock pond at an arboretum. It was 50 degrees out and breezy so I tried to convince her otherwise. But she was persistent and I let her. She loved it, she played in there happily skipping around for 30 minutes.

The pond water was heated.!StumbleUpon!

Who's Online

We have 13 guests online


Featured Links:
Joomla! The most popular and widely used Open Source CMS Project in the world.
JoomlaCode, development and distribution made easy.
Joomla! Extensions
Joomla! Components, Modules, Plugins and Languages by the bucket load.
Joomla! Shop
For all your Joomla! merchandise.

Login Form