you are here: Home Blog Adoption

Most of us have heard of the term 'Scrum but' - it refers to groups that are trying Scrum but are having some challenges.  For example, a group that is exhibiting 'Scrum but' might say something like 'We are practicing Scrum, but our sprints are anywhere between 6 and 8 weeks;' 'We are practicing Scrum, but we don't always deliver working code at the end of the iteration.'

Yes, these are bad situations.  But lets look at the flipside - lets look at the 'But Scrum.'scrumbut

Del.icio.us!StumbleUpon!
  • 0 Comments

This is not about agility, this is about acting responsibly.  Developers - stop making excuses not to test.  Managers / Product Owners - stop accepting myths about why testing isn't happening.  With that in mind, I present you the top developer testing myths (some of which I have even said).

Top Developer Testing Myths

  1. I don't have time to test
  2. The code is simple / its a small change / I'm too smart to need to test
  3. There is all this legacy code, its too hard to test now
  4. That's certain person's code, I don't want to touch it

I don't have time to test

Del.icio.us!StumbleUpon!
  • 0 Comments

When I left my previous employer, one of my goals with my next gig was to have it expose me to other domains and environments.  I wanted to get different perspectives, see Agile at different scales, and help spread successes as well as see the challenges and assist where I could.

I've been doing this now for a bit and I can tell you a few things for certain -

  • The answers are far easier than the implementations
  • You are not alone in your struggles
  • People are succeeding even though they might not be considered 'Agile enough'

The answers are far easier than the implementations

'We have a large amount of dependencies in our projects.'
'Reorganize your work so you don't have dependencies anymore.'

'Our testing and regression takes too long.'
'Test sooner and automate as you go.'

'We have a large amount of dependencies across teams.'
'Create cross-functional teams that are customer focused to remove dependencies.'

'We have an international, cross-time zone, development team so stand-up times are impossible.'
'Restructure your teams so everyone is together.  Oh, and get rid of all the walls between members, make sure everyone is pairing, and for bonus points make sure everyone is using a PowerBook and they sit on beanbags.'

My team and I are frequently asked for advice or pointers with some very common Agile or organizational problems.  While I personally like the discussion, the reality is I hate the answers.  I hate the answers because its the easy out.  Looking at problems and providing a solution is easy. Even helping create a plan to address the problem is easy.  Implementing the solution or the plan is hard, ripe with unforeseen problems, potentially painful, and most definitely will take a long time.  Providing an answer or a plan takes a few minutes to an hour.  To implement these solutions and actually have them stick will take a large amount of time and commitment.  Do you want to address quality issues?  You can't just have train people in TDD and test automation and expect everything to fall in place.  Chances are you will have to look deeper - look at your hiring practices for example.  Are your interviews focused on obscure API calls or are they focused on quality?  How do you create an organization that actually cares about quality, and by doing so not create one that is scared of ramifications of creating an unforeseen bug?

If you work in a traditional matrixed organization, trying to create cross-functional teams isn't as simple as creating a team and telling them go.  There will be headcount issues, territorial issues, domain knowledge and specialization concerns that have to be addressed.  You might actually be worse off for 6 months or a year - can you commit to that and see the light at the end of the tunnel?















Del.icio.us!StumbleUpon!
  • 0 Comments

Just worry about why for now I've said it before, and here I am saying it again - Change is hard.  The largest obstacle to any organization looking to adopt more agile practices is that transition - we are creatures of habit and now we are being asked to do something else.  One of my favorite 'Agile Dudes', David Hussman (www.devjam.com) talks about Dude's Law - Value equals 'Why' divided by 'How' (V = W / H).  The point here being that the more we can focus on why we are doing something rather than how to do something, the more value we will get from it.  When we look at Agile transformations, keeping Dude's Law in mind will help with the pain of change - explaining to our co-workers why we are looking to do something instead of telling them the new way to work will be better accepted and ideally lead to an environment that promotes continual improvement.  With that being said, I wanted to put together a quick list of some items you might be interested in trying and why you would want to do such practices.

Short, focused, development cycles

Del.icio.us!StumbleUpon!
  • 0 Comments

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?

Del.icio.us!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.

Del.icio.us!StumbleUpon!

Regardless of the methodology you practice, continually improving should be your goal.  We want the product to be better, we want better quality, we want to work more effectively.  Agile, and retrospectives in particular, are effective in helping us improve because of the tight feedback loops and team ownership. How are we doing outside the team though?  Does your company have strange rituals that no one understands and no one can seem to change?  Do you have organizational OCD?  Say for example...

A team wants to deploy their software to another environment for testing...but they have to fill out a form and wait for a DBA to execute the SQL script to update the database.  That person executes the script and walk away, leaving the team to flail with questions. 'Did all of the data update? I don't know, I can't see it.'

Del.icio.us!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.

Del.icio.us!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:

Del.icio.us!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.

Del.icio.us!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.





Del.icio.us!StumbleUpon!