Get (really) Agile with your next software project

I once had a job interview with a CEO who very proudly proclaimed to me that his company had been doing Agile development since before it started getting called “Agile”.

I accepted a position with that company but was surprised to discover that while they occasionally had a “scrum” meeting and used the term “sprint’ – they had no EPICs/user stories, no unit testing, no continuous integration or continuous deployment, no iteration planning meetings, no point estimations, no velocity measurements, no retrospectives, no burn up/down charts/tracking, and no automation testing. 

 I quickly realized that this CEO may have been confusing the literal meaning of the word “agile” with the development methodology and principles of the same name and thought they were Agile because that were flexible with dates and requirements.

This was certainly an extreme example, but I believe partial implementations are far too common.  When hiring, I used to ask any product manager, QA engineer, or developer candidate what development methodology was used at his or her last company.  If the candidate knew what Agile was, the answer was amazingly consistent and indicated the organization was only partially agile.  I have probably asked this question over 100 times over the past 5 years, but never once heard somebody state that their organization was 100% “by the book” Agile.

Pure or 100% Agile may only largely exist in the classroom – and I think that is fine.  Every organization needs to adopt the principles & processes that work best in their environment.  But have they adopted enough of them to actual reap the benefits that the methodology and principles aspire to deliver?   In far too many cases, the answer is no.

Far too many Agile conversions/implementations are only partly successful.  Companies it seems, are willing to live with only a partial return on their investment.  Why does this happen?  I believe there are a number of reasons.  An Agile conversion takes discipline and dedication and willing to live through bumps on the road on the way there.  Not every company will stick with it, even if they invested a lot of time and energy into it at the beginning.   Unless it becomes engrained into the culture, it is easy to only adopt the principles and processes that are easy, and let the things that require more rigor and discipline fade away.

Often, Agile adoption is somewhat doomed from the beginning. Sometimes companies send product owners, project managers, and developers to Agile training and then expect them to come back to the office and start doing it.  Others bring in an Agile coach to try to teach their team how to do it.  But what happens – why does this often not work?  There are a number of reasons, including:

1)  Training is often ineffective because the team is too busy.  How many companies can afford to give up their development team for training?  They have deadlines and are behind – that is why they are considering an Agile conversion in the first place!  So only some are sent to training, they get distracted by emails and issues that come up back at their office and they only retain a small portion of what they are trained on.  When they come back to share with others, the others get only a tiny portion of the important content.

2)  Training is often ineffective because the subject matter is BORING.   These are often technical folks in the training that love learning about new technology.  Not new principles and processes.  Yuck!  

3)  Team members see classroom examples of development tasks during training that are simplistic and nothing like what they would see with their own applications which gives them no applicable context to appreciate the material.

4)  Because everybody hasn’t been trained yet and there isn’t total adoption on day 1, team members don’t always get the chance to exercise what they have learned right away and it is often lost over time.

So how can this be overcome?  The best method I have seen for gaining real Agile adoption is by utilizing an Agile Development Lab.  This is a far different approach than some of the traditional methods companies have chosen.

Companies utilize a development lab not specifically to help them with Agile conversion/adoption.  They utilize the lab to help them with the rapid deployment of the project or application they are trying to deliver. – the agile therapy comes as a side benefit.

Here is how it works:  A companies’ software developers are paired up with the Development lab’s developers, who are typically subject matter experts on the technology the project is using.  Even Technical Product Managers are paired up with Technical Product Managers that are part of the development lab – it isn’t just developers.  The team works in Extreme programming pairs until the project is completed.  This helps a company get their project completed and product deployed rapidly because they get experienced expertise working on their project with them almost immediately.  They follow the development labs processes, and the team gets to see exactly how it is done as they work side-by-side every day with the lab personnel.  Unlike outsourcing, at the end of the project, the internal team knows the code and has learned the technology and can be self-sufficient from there.  

So why are development labs an effective way to gain Agile adoption?  I believe there are a few major reasons why I have seen this be effective:

1)  This isn’t an Agile “training” that takes days.  This is an observation and practice over a period of time.  The team sees how another team does it, starts practicing it with them as they work on the project and it naturally becomes second nature and part of their own development culture at the end.  In fact, they often become the “Agile” advocates in their organization when they leave the development lab and go back to their company office.

2)  It has the right context.  They are practicing Agile with their own real life company projects and see how it helps them and applies to them personally; unlike the simplistic examples they would see in a normal agile training session.

3)  Lack of compliance with certain agile principles is not acceptable.  Whether or not to write a unit test is no longer an option/decision.  The team is working with somebody on a daily basis that will require it.  It gets ingrained into the process as the norm, not the “new” thing or the exception.

4)  The team sees experienced/knowledgeable people adopting it and trusting it instead of seeing team members struggle with it like they might when trying to migrate in-house.

Many companies are scrambling to get their big data projects and other cloud application projects developed and deployed quickly.  A development lab is a great option for them to consider for not just the quick development and rapid deployment it brings, but also for the side benefit of becoming more Agile and seeing the ongoing benefits (continuous, predictable, quality releases/deployments) that come with it.