Most organizations, especially the older more enterprise ones, are crippled with environment complexity - what started as Dev / QA / Prod quickly had a stage environment added, maybe a UAT, then perhaps a few QA environments for various versions. Sitting on top of those numerous environments may be race conditions - who can test when - as well as challenges with getting data, content, dependencies, etc in the right environment.

The problem here is that this view on 'move my application through environments' is fundamentally flawed. The environments were a response to an unknown. We need to be able to test this outside of a dev workstation - create a qa environment. We need to load test this - create a pre-prod environment...and so on.

A common concern I hear when working with teams is how much time should we spend in design or architecture of our product. I had a real nice conversation with a team last week around this topic and wanted to share some of that discussion.

The conversation started with a comment around 'we were told in agile we don't do any design. That seems crazy. How do you find the right balance.' No design or architecture consideration ever is crazy.

Jen Krieger (@mrry550) tweeted a very nice comment around her excitement for the DevNation sessions around DevOps and Continuous Delivery, along with a nice write-up on her blog here. Reading the blog posting, I thought I would shed a little more light on my presentation at DevNation, namely my perspective and the motivation for the session.

The motivation for my session is pretty simple - Continuous Delivery can be pretty awesome. It can help teams create awesome products in an effective way and create environments where there is less failure noise (bug discussions, system instability, etc) and more focus on building cool things that help people. We all want to build.

Continuous Delivery, as I see most organizations looking at it, reeks of failure demand. Blinders are being put on to why problems are occurring and, instead of addressing those problems, people in authority say 'We need Continuous Delivery....' and so teams run off to choose their continuous delivery tool. Too many organizations are running to Chef / Puppet / Ansible / Salt / etc without reflecting on what is jacked up internally.

If your products are of low quality, what value is there in delivering more horrible stuff faster?

Ninjas are everywhere, or at least musical ninjas are needed everywhere if you believe the job hunters. 'Super awesome company looking for ninja rockstar to save their ultra cool application, big data in the cloud experience a must!'

Recently I have noticed that larger, more 'classical' organizations are looking at doing 'Hackathons' - short time frames where people are employed to hack on code, possibly to create new interesting ideas. Organizations hear about Facebook, Twitter, Spotify and the like doing these hackathons with great results - employees like them as a creative outlet and the general influx of product ideas and innovation among other benefits.

Here is the catch - Hackathons are not magical and hackathons alone don't create this enthusiasm or product engagement.

Standard background - I believe in open source, always have and always will. With that in mind, the comments below are not a knock on open source, they are an expressed desire for better software experiences and better products. I hope that some of the observations and learnings below will lead to better JBoss solutions as well as hope it helps teams in general reflect on their products and the message it is sending.

I had sent some of these comments around to my peers and former colleagues and there were requests to make this more visible. With that said...

Regardless of popular sentiment, there is still a large number of organizations that are estimating their work. Lets put the validity of story-point estimating as a necessity aside – accept that, for now, there is some need that is felt to be filled by estimates. If you must estimate, please do not estimate your defects and include those in your velocity calculations.

Lately I have been noticing a concerning pattern around organizations leeping to Kanban quickly. From what I have seen, organizations value cycle time. Well, either that or it is a new interesting metric that enterprises are still learning how to cheat. But I digress. Let's assume that organizations honestly value cycle time and the belief that making that predictable and exposing bottlenecks will make their product deliveries smoother. Great. I agree.

The implementation is similar to the challenges we have with 'agile adoptions' - most organizations following the Analytic mindset (@flowchainsensei) - can't rethink how to structure work. Instead, similar to 'agile adoptions', what I am seeing with Kanban is bending an idea and opportunity for change until it buckles...and becomes another process in a standard analytic model. Let me explain.

An interesting scenario unfolded in a recent training session I was co-teaching. During some introductions, we asked the group to identify with a skill - leadership, testing, questioning / discovery, design.

The majority of the group (~70%) chose leadership as how they would identify themselves.

Company re-organizations, which seem to happen every few months, focus primarily on financial efficiency, usually at the cost of context to their staff. Shortening the distance to context may very well cost more, but reducing this distance will create a simpler environment that costs less to maintain and grow.

I was sitting in a technology conference session recently and, rather quickly, started focusing more on the presenter than the content (perhaps because the content was less than stellar). Either way, this started me thinking how much easier it is to find faults than fix our own.

This may seem obvious, but just think about it – even in positions of inferiority (in a session to learn or discovering how to create a product) – it is more natural for us to find faults in others or a process than actively work on resolving our own or helping others to improve.

I consider myself lucky to have a varying group of individuals that I have met over the years with whom I can speak rather frankly about products - not just delivery but discovery. I have seen an interesting pattern evolving - people want evangelists. Gone are the days where it was enough to be a solid developer, great requirements writer, or an effective manager. The times - they are a changing - and that is a really good thing.

I was speaking with a colleague a few weeks back who was working on somewhat of a startup and was using outsourced development. He asked me a seemingly loaded question - 'How come the developers only care about me telling them exactly what I want, then they hide off and come back with something I don't need?' 'Well,' I responded, 'you are working with the wrong developers.' By nature, the outsourced model is designed to remove any collaboration and focus strictly on savings based upon contractual obligations. Perhaps a better name would be 'sunkcosting'.

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.'

In 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?

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.

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

I don't have time to test

The code is simple / its a small change / I'm too smart to need to test

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?

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.

Growing up the youngest child meant that my closest brother (6 years my elder) would terrorize me with threats of the boogie man coming to get me. It was a rather effective tactic - how to deal with the boogie man wasn't well known and the internet was just a glimmer in Al Gore's eye. I see and have been part of a similar tactic in software development. I have terrorized product owners and business sponsors with the concept of technical debt.

'Ooh, that change is going to take a long time. That code that so-and-so wrote 3 years ago is real bad.'