Month: May 2016

Hey John, Don’t Abandon Agile!


I was speaking to my buddy, let’s call him John (quite possibly because his name is John). John is a good friend who also happens to be in software development.  We were having a nice chat about our families and such when our conversation transitioned to our work. That was when John dropped the bomb on me and said, “Hey Phil, I know you’re a big proponent of Agile and my company does Agile, but you know sometimes you just have to abandon Agile and get things done”.

I don’t think my buddy John is the only one out there thinking this way.  What Agile adopters need to understand is that Agile will uncover and shine a spotlight on issues.  If organizations don’t have a healthy practice of inspecting the issues, identifying root cause, creating action items and conducting remediation – then they won’t move forward.  Why did we miss expectations? And if you can’t answer that question then ask “why” four more times.  It is so important for remediation on prioritized issues.  If you don’t, then you might take the position to abandon Agile, but in reality you have not followed the rules of the game because you have not addressed the root issues Agile has uncovered.  If your organization has been practicing Agile for a while and you feel, as my buddy John does, then I would challenge you with the questions below.

Can you utilize retrospectives to identify the root cause, prioritize action items and at the very least chip away at fixing them?  Sure, you may not be able to address everything or even half of what you find, but can you commit to start?  What issues do you face?  Does your organization experience some of these issues below?

We can’t do a two-week sprint – it takes us a week to test this stuff!

The end goal is to create a test-driven development environment.  In the interim you can do your best to create automated tests.  It may not be easy, but start to carve out some time and at least create automated testing around some of your more visited code.  Try to adopt a policy to have automated unit testing done for new code.

OMG!  Look at this code!  This needs a complete overhaul!

Don’t grow technical debt without a conscious decision to do so.  Even if you don’t practice pair programming, setting up a practice where there are peer code reviews or more than one set of eyes on the code is good practice.  If you don’t do this, you are probably working in an environment where over 30% of your time is spent complaining about and/or addressing technical debt.

We conduct retrospectives and identify needed improvements, but we don’t have the time to fix them!

If you have a hard time acting on issues found in retrospectives, make sure you create product backlog items for the action items and prioritize at least some to be addressed.  Make sure you’ve identified the root cause and address at least one or two per sprint.

Man, they just keep loading us up with things to do – we can’t keep up with this!

This is tough if you don’t have executive support.  You’ve got to have prioritization in place for initiatives. Strive to get an agreement in place for a work in progress (WIP) limit at the initiative level. Create an information radiator Kanban board showing all the projects and their state so it becomes apparent to everyone that there is a lot going on here.  Cull and keep your product backlog to a manageable number and notify stakeholders when a product backlog item is being deleted.  There will always be a higher number of requests than can be done.  If the stakeholder does not want it deleted, then they need to make the case for its priority.

They just told us about this the other day!  How can we get this done!

Identify the root cause of why you received this request so late.  If this happens often then record these events in a spreadsheet and have a discussion with needed individuals to uncover root cause.  Did another department sit on this request?  Is it a late request from a 3rd party, regulatory body or vendor?  Do your best to meet with the appropriate people, address and fix the situation.

They keep on interrupting our current project with another emergency project!

When you start working on a project do you define the smallest amount of features that you can deliver?  This is considered to be the minimal viable product (MVP).  Small batches are more efficient and at least if you get interrupted you have a better chance that you will have delivered something.  An emergency can happen, but if it becomes the norm then you’ve got more digging to do for root cause.  If you’re constantly stopping one initiative to start another, then you also may not be working on the right things.  A lot of organizations don’t have the proper scrutiny around economic feasibility (possibly my next blog) and without that objective measurement the newest squeaky wheel can sell anything as an emergency. Software started and abandoned cannot be seen the same as unfinished product laying around the manufacturing assembly line, so this happens more than we like to admit.

We’re dead in the water waiting on this other team!

Strive to create cross-functional teams, so you are not so dependent.  In the beginning this can be tough and cannot be done for everything at once, but if you don’t try then you will pay the price.  The biggest waste in software development is found waiting on dependencies and cross-team communication.  Think of creating a Kanban board displaying cross-dependencies.  This can assist in identifying queuing issues.

This issue happens over and over and is just killing us!

Continuous improvement is needed.  If you identify issues, but don’t act on remediation then you are not going to grow.  Capture the action items in product backlog items and prioritize at least one every sprint if you must.

This code migration is taking forever!  The code worked in test so why isn’t it working in production!

Do your best to move towards automated builds and continuous integration and delivery.  Couldn’t leave this one out, but even like some of the others – this could be its own blog subject.

Is this Agile?  What the heck are we doing!

Get an experienced Agile Coach to guide you in your transformation.  It will be worth it.  When in doubt refer to the 12 Principles of Agile.

This guy sits right across from me and he’s emailing me on this!

Do whatever you can to create trust throughout your team and organization.  That’s one of the top reasons people continue to use email.  Try to speak to people if you can. Get to know the people you work with.

I can’t get all these tasks they gave me done!

Eliminate as many dependencies as you can.  Try not to work on more than one thing at a time.  Context switching will cost you 20% of your time per item.  The more cross-functional your team becomes the less chance that tasks will have to be done by one person.

As Agile implementations fail at some organizations because we didn’t address the uncovered issues, Agile will probably take the hit.  Let’s try and prevent that from happening, by just remembering to nurture, care, feed and grow our Agile transformations through continuous improvement. Hopefully, some of these scenarios have hit home and illustrated that Agile may not be failing us – we just may be playing the game wrong. Concentrate on continuous improvement for the issues that Agile is uncovering.

Oh, and John and I will still be the best of friends after this blog because, you know, healthy conflict is a good thing.  Love you brother!