Agile isn't just for code hipsters
I've honestly seen people physically turn up their nose to the idea's of doing anything with their software in an agile way.
Agile software development is a collection of tools,processes and patterns of working with software that allow for the inevitability that your and/or your business in fact might change their mind about something, or decided that something was forgotten etc...
It is by no means a prescriptive way to develop software. Don't expect to follow a checklist and expect to solve all of your problems. Most likely your issues aren't technical anyway. I've seen a lot of software projects turn into albatrosses because of the ego's of the individuals involved, it had nothing to do with software process (Agile or Not).
Common arguments against Agile
We aren't a software development shop
This statement sends me through the roof. It is a bad way to look at your software ecosystem. I believe individuals that say this are most likely viewing software as a necessary evil to getting their business done. It does imply that because they view it this way, this necessary evil doesn't really need to have good engineering.
Let me ask you this. Do you ask a cabinet maker to come into your house and then spend time convincing them that his job isn't to really make cabinets the way he has been trained, but because your house is a special snowflake, he has to do everything with one hand behind his back and only use a certain color of wood, and no hammers.
The idea that you can remove certain processes from the activity of making cabinets will somehow yield quicker, cheaper results. This could definitely be the case, but then what about longevity? Why do you care so much about how they do their job right now? Are you a carpenter too?
We have to know when we will be done because we have client contracts. Aka hard dates
This is another false assumption about software that it can be done based on a time window. This is only true in a vacuum. Meaning, that as long as the requirements don't change and no other dependencies change then sure planning something should be pretty straight forward.
How many projects have you been involved with where
- The customer knew all of their requirements up front
- The customer adds no additional feature requests (effectively changing the scope of the original project if they do)
- Dependent technologies or downstream services all behave swimmingly.
- There is no technical debt causing friction in your code changes
- Project finished on time without any feature changes
If you think you've been on a project that well defined, awesome! But I doubt many of us have.
So being honest with ourselves, we can't actually know with 100% certainty that a project will be done as it's currently defined by the date set. Most projects I've been on have had changing requirements.
Paired programming is wasteful
This is one that is commonly brought up in regards to paired programming. It also stems from the fact that somewhere someone got it in their head that Agile = Paired programming.
Any organization that implements Paired programming prescriptively without knowing why, is bound to have a hard time with it. The value isn't readily apparent when you see two developers sitting at one computer. Instantly we think, well crap if I had two people slinging code, I could move 2x as fast. Then we start getting into the fun world of trying to get 9 women to make a baby in a month. It ain't gonna happen.
Pairing covers a few key concepts and should only be done when it makes sense. What does make sense mean here? Well you have to make that judgment call.
I propose you pair in these situations:
- New Developer on boarding
- Working on a particularly complicated algorithm or Domain Space
Now if your developers are effective when they pair, don't stop them. If you notice one of them spacing off and not engaging, then you might have something to work on with that individual.
You either get "it" or you don't
Agile is a non prescriptive set processes, behaviors, and ways of managing software the ways it's actually created. Any business should be able to to do software development this way.
So if we can't predict specifically when a feature will be done because we're pretty sure we don't know everything we need, or the customer doesn't know everything they want/need. How do we go forward?
Pick a target
Well, you still need some sort of target. Some planning is always good, but don't over plan. If we assume that stuff will change when we hit the implementation phase, don't over specify details that are unimportant overall. Try to talk about your software with your customers as a set of capabilities. Try to avoid technical detail minutia with those that really shouldn't be making a decision either way.
Iterate to your target
Once you have a target create frequent checkpoints with the consumer of your feature. Don't go off and break your code for 2 months doing a "refactoring" BTW a refactoring should have the same behavior after you're done. If the behavior is different that is considered a code change.
Create tests at the right levels and scopes. This is probably one of the highest contention subjects to talk about amongst the various teams I've been on. I've done TDD and BDD styles and both have their purpose. The slippery slope with TDD is over coupling with tests. For example to test your class for behavior.
- Changing accessibility of members if they don't need to be exposed. Making a method public just to test it is a smell.
- Testing POCO's (Plain Ole C# object). They shouldn't have behavior and are just structures, why couple to them?
- Testing Private classes. Usually privates are that for a reason, and this is ok. It's still valid to test the private class behavior through a consumer if you own the whole chain of things. This is something that takes some getting used to, because it flies in the face of what a lot of us think TDD is about.
Let the client decide what done is
Frequent reviews will show that sometimes the customer is ok taking the work early if not as completed.
Sometimes it's a matter of having a conversation with them and asking the question "What is the minimum set of features needed in order to get some benefit". If you can get them to be ok with defining a minimum set of work, this is your first target, and the customer has defined it for you.