Why don't small companies do big-A-Agile? Are they agile by default? Is Agile just a way for a large company to behave more like a small one? In this retrospective on agile adoption in companies large and small we'll look at what drives adoption, how effective it is at meeting those goals and whether software craftsmanship could teach us more.
Java developer Agile enthusiast Aspiring software craftsman Co-founder of LSCC Twitter Why don't small companies do Agile?
Start with some definitions Tried doing by numbers About names not roles â We need Mike to help with thisâ â That's a job for Rachelâ In large co â We need QA to help with thisâ â That's a job for the operations teamâ Not to say ppl donât know each other Identifying by role/team creates short hand â but creates barrier
We mean agility Responsiveness; ability to react Bottom up â enthusiastic developers introduce specific practices
Agile goes mainstream Big-A-Agile is how we try to get there
Take away the theatre and buzzwords â agility is pretty simple Iterate!
XP practices fit this perfectly Scrum & kanban provide structure on top â forecasting, planning & process improvement
BA vs talking direct to customer Requirements review; architecture standards committee; design sign-off Not been in business long Large business, older, more time to build legacy Interesting metric: LOC/developer 50k 10ppl = 5k/dev 1m 20ppl = 50k/dev Large companies, more code & more code per-developer More to remember Harder to change Software factory
With less inventory, even starting on wrong foot easier to retro-fit tests Dev owns junit tests; BA owns acceptance tests; who owns browser tests? QA or dev? What if they're written in junit?
Small company trying to find product market fit â canât wait
So small companies naturally do something approximately agile; what stops a large company replicating that?
Byzantine process â dedicated job to navigate Failure of an alternative, nervous management return to process safety net â Weâre doing agile, but...â Requirements review, design sign off This isnât âscrum, butâ â its âwaterfall, but weâre pretending its agileâ
Separate QA, build, operations team More people, more meetings, more waste
Everybody âdoes their jobâ, instead of delighting the customer â I fixed the bug, it's up to QA to test itâ â I raised the defect, I'm waiting for dev to fix itâ â The build's ready, operations need to deploy itâ â It's the maintenance team's job to fix bugsâ Thrashing - reviewing possibilities / changing direction
Development is documenting requirements Start from vague ideas; most precise form is code Project idea has a lot of appeal â but software is weird stuff People feel threatened by agile
So why do large companies do big A Agile... Or the stupid...
Coming from waterfall background, or half arsed agile
What would a diabolical agile roll out look like? How would Dilbert's PHB do it?
Project mindset Have team size, fixed scope, fixed date Backlog full of mandatory stories Extra credit: new to company
Alpha geek & passive-aggressive cynic Solve all design problems â can't estimate without understand what we're building Everything is a 5 anyway Might feel like planning theatre, but its important to be able to hold developers accountable for their commitment
Sprint end â stories not done carry over Process set in stone, can't change it But of course, this isn't agile â it's a checklist of behaviours
Now agile is mainstream First line of the agile manifesto Ironically...
If big-A-agile isnât the answer for large companies, perhaps software craftsmanship provides a better view?
Software craftsmanship typically focuses on the individual developer How can I improve? How can I learn? How can I mentor others? Iâd like to go off in a slightly different direction â if I built a team of craftsmen, what would that look like
Responsible for, and capable of , delivering a working increment More dependencies, more project management Developers want to understand the business Let them work with the customer, not for the customer
Bob Martin talks about 1 master, 3 journeymen, 9 apprentices Fred Brooks âIf a 200 man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back programmingâ
If team responsible for customer to production; all process is internal to team Conforming to standard should be choice of team â because itâs beneficial to the team Some mandatory â rest owned by team
Most developers need to work harder on improving quality; very few over-engineer Rush design, multiple code rewrites Skip unit testing, bugs found late â expensive to fix. Not my fault â unlucky Bugs thrive in crap code; debugging crap code takes time -> just fix the code! Scrum/kanban etc give ways of tracking velocity/cycle time to make projections based on past experience If schedule is slipping, cut features not corners
So how does craftsmanship help?
Developers understand the business; customer trusts the development team -> what to build next. Small, autonomous team; with right experience; producing clean code -> implement smallest thing One team (devops); minimal, self-improving process; working in partnerhsip with the customer -> get feedback quickly On top of the XP practices, craftsmanship is about the relationships, the team structure and a focus on quality
XP is about the day-to-day practices What developers do
Scrum is about the iteration-by-iteration practices What project managers do
Software craftsmanship is about developers âraising the barâ But itâs also about building the right team and genuinely empowering them to craft great software This is in management âs domain Craftsmanship has these four key goals to enable agile delivery: autonomy, experience, process & quality â let me summarise my thoughts about this into what I think the software craftsmanship manifesto should have said
We donât want dependencies, scheduling and project management â we want autonomy We donât want armies of untrained developers â we want to hire great developers with a balance of experience and help them all progress We donât want long process definition documents â we want permission to use the right process for the job Finally, we have to stop writing crap thinking its quicker. If we do the job right, speed will come naturally.