I’ve worked with (and supervised) developers who I’m fine with sending off into their corner to do what they think is best for weeks at a time. I’m confident they’ll come back with something great, more often than not. I’ve also seen developers who I’m not comfortable with sending off on their own for even a day in between daily standups.
I wonder if there’s a process that allows to reap the spoils of both types of developers. Naturally, I’d rather have a team of the first type and think hiring those is the best way, but inevitably, some of the second type make their way in.
The agile framework can still be followed by the project leaders, but the developers (who don't like micromanaging) can be shielded from any rigidness.
yes, making plans that you indend to continuously adapt to the situation at hand doesn't conflict with agile. but that still leaves one wondering what agile really brought to the table. time boxing everything at a fixed 2 week interval?
I recently observed from the outside a project that took upwards of two years of requirement elicitation, IP contracting, complex distribution of ownership between multiple competing companies, multiple OS's, complex hardware platform design revisions to support the intended software functionality. Not a single line of code was written for two years. Was this state of the art engineering? YES. Did they operate under the principles of the agile manifesto? YES.
It's not a strawman. Those organisations are very real.
> yes, making plans that you indend to continuously adapt to the situation at hand doesn't conflict with agile. but that still leaves one wondering what agile really brought to the table. time boxing everything at a fixed 2 week interval?
Agile emphasises that you need to deliver something working to the customer, every 2 weeks. Without that it's very easy to call something code-complete or tested but not released or whatever, and you get further and further behind where you think you are because none of the stuff you thought you'd finished actually works.
Agile manifesto, 2nd point "Working software over comprehensive documentation".
It certainly doesn't stop you but if you focus on writing comprehensive documentation before working software, it is not Agile, it is something else.
As for Agile offering "protection", maybe I misunderstand your point but for me, Agile is the opposite of protection. I think that if there is one thing that defines Agile, it is that the customer is very close the the team, so it can be, well, agile. The customer has to be there to see how things are going and adjust course as necessary, unlike the waterfall style where a formal contract protects both the team and customer.
Note that I don't consider "waterfall" bad, and "Agile" good. It is just different approaches for different situations. If the customer wants an "hands off" approach, or if you write certified software, then I believe that "waterfall" style approaches are superior most of the times.
Isn't the 0'th point that agile still values the stuff on the right, it just values the stuff on the left more?
Which is funny given that the father of TDD, Kent Beck, is one of the Agile Manifesto signatories. What does TDD give you before working software? Comprehensive documentation.
Tests serve a different purpose. They are not for humans to read, they are to make sure your software works ("working software"). They are an important component of Agile because it makes it easier to change your code without breaking things.
Now, I am not big into TDD, but for me, it is an approach that is fully compatible with the Agile manifesto.
Test is the action that is carried out from the documentation, possibly by a human, but more likely by a machine. We are talking about the document that describes what the program is intended to do, which is then followed to carry out the tests.
> They are not for humans to read
I should hope your documentation is there for humans to read. If not, even small modifications required as business needs change would become a complete nightmare. The tests you need to perform, and thereby the documentation that needs to be followed, will not remain static through the entire lifetime of the application.
It's not comprehensive documentation, it's a process of software development. Start with the most simple test first, make it green via the most simple implementation, refactor. (Red/Green/Refactor). Repeat until you can not adjust your tests/specs and implementation anymore.
Doing TDD you'll not create comprehensive documentation upfront but will switch your testing- and implementation-hat every few minutes.
Not at first, but by the time your software is working, you will have comprehensive documentation about it.
> Doing TDD you'll not create comprehensive documentation upfront
Where did the idea of 'upfront' come from? Having comprehensive documentation before you have working software doesn't mean having comprehensive documentation before you have any software.
I suppose if you did a pre-planning phase like ours but comprehensively documented your entire product and then delivered exactly to those docs 8 months later without input, you'd not be doing agile for sure.
When I say protection, I don't mean protection from the customer. The scrum process protects the team by requiring the ICs on the dev team to choose the user stories or work items which will come into the sprint. This prevents management from committing the team to work they themselves do not think can be accomplished. This meeting should leave a written record which is shield but also the acccountability for the dev team.
Basically you try and get as much of the feature implemented as quickly as possible. Forget tests, forget well-named identifiers (just call 'em foo1, foo2, foo3 if you're stuck), forget breaking other part of the app, just get enough of the feature working as quickly as possible that you can identify pain points. If you get enough of it working it can even be used as a prototype for the customer to play with to see if they actually want it.
Of course, when _and if_ you decide to actually implement the feature, you gotta throw away all your spike work or you're going to have a bad time. It is of course perfectly acceptable to keep it around on another branch for reference.
From a TDD standpoint, I also use the word "spike" to describe any quick experimental throw-away work done on a small slice of functionality before writing the first test. These should not have tickets as that would be a bit over-the-top (and you don't always know if you're going to do them).
Every project I take on these days has a pre-production phase. This phase is 1-3 sprints. It involves speccing sophisticated systems, designing UX and several spikes to evaluate technology. These all have outputs in the form of documents. Even the spikes should produce a short document outlining the technology recomendations and the reasons for the recommendation.
Similarly, in a project with a more research orientation, we perform spikes which involve building various prototypes and documenting their feasibility.
None of this conflicts with agile principals nor creates a situation in which engineers and designers are pressured to forsake, "building it right".
In fact the only differences between this approach and "waterfall" is that there is frequent accountability and there is protection for the development team because they are still choosing what comes into a sprint.
I generally find that whatever form the various criticisms of agile take over the years, there are generally two impulses really at work underneath them. Either management is trying to undermine the protections agile and scrum create for the dev team by violating the "only pigs talk" principal or it's developers trying to avoid regular accountability so they can build their castles in the air.
To be 100% clear, I'm not even saying that approach never works. There are phenomenal developers who disappear for weeks and come back with magic. But often enough, developers who cannot deliver try to perform the same act and their incompetence sinks a project. The development team cannot collectively afford the risk to find out which kind of developer you might be and therefore you owe them accountability. We all owe each other accountability.