Category: Life the universe and everything

We do scrum-but and it’s fine

Published on by Klaus HarrisLeave a comment

It seems that the debates about scrum are always ongoing and it or agile development in general is still a pretty hot topic. There’s even a new job role ‘agile coach’ as more of an industry is built around it. The world is ever more moving online and getting more digital, so it’s a big market.

I think too much is expected of scrum and agile practices and that it is viewed particularly by non-technical people as some kind of development process panacea. It’s also worth remembering that scrum came more from the project management side of things rather than the technical side like extreme programming (XP).

My first scrum project was in 2007 and it was text book stuff. I was in the ‘chosen’ team working on a cool new green field project in a special room and we even did planning poker (for a while). Over the years, in different companies we all did what I now call “scrum-but”. I got this phrase from discussions with people in different organisations asking how they do scrum. It goes like this:

“So you’re doing scrum right? How’s that working for you”

And the answers would invariably be:

“Yes we are doing scrum but we’re not doing this.. “
“Yes we are but we’re doing this…”
“Yes we do scrum but..”

In short “scrum-but”.

The real world is different than what you learn in scrum trainings or read in the books and I’ve seen a lot of this:

  • Product owners have a very clear idea of what they want and don’t consult the technical staff until just before the project start. Technical viability and cost is often not explored
  • It’s worse if design agencies are involved because then there is no room for feedback, it really is just a case of ‘implement’
  • Often, there is little concept of minimum viable product
  • Real user feedback isn’t gathered until just before the release or after, there is no feedback and altering of requirements until it’s too late
  • Stakeholders and owners often don’t care about the technical details, maintainability and quality and if external code shops are involved, they will probably not be thinking of how the thing will be in five years time
  • Scrum is fine for projects but once the project is released, it then goes into maintenance and extend mode. What then?
  • Technical teams are often working on multiple areas at once, new work, maintenance and ongoing development work. That doesn’t fit with the idea of nice clean projects and backlogs
  • Not nearly enough focus on fundamental technical issues such architecture, quality, testing
  • And for agencies, how do they manage billing and cost estimates if the whole thing is done iteratively? This was a big topic for agency managers on a scrum training I went on and the answer was “look, scrum doesn’t solve your business model problems”
  • User stories like, ‘As a log file I don’t want to see error message xyz’

After I did a scrum master training in 2012 none of this bothered me any more regards scrum, because I realised that scrum was a square peg in a world was full of round holes. And from then on I decided to just take the good bits from scrum, other lean principles, XP and just make them fit the need and environment, ‘scrum-but’.

I think the trick is knowing where the line is on technical compromise, that’s personally where I don’t budge. Make sure here you have a strong technical lead who gives honest feedback. At the end of the day, corny as it sounds, project success and ongoing success is about people, teams, trust and responding correctly to business needs.

Martin Fowler reposted this post from 2009 last year, and it’s as valid now as then. http://martinfowler.com/bliki/FlaccidScrum.html

My take on a Consultant’s Tale – from a software development angle

Published on by Klaus HarrisLeave a comment

This little story comes from a magazine I saw recently in a waiting room somewhere and it set me thinking:

Every day a small ant arrives at work early and starts to work immediately. She produces a lot of and she was happy.The newly appointed Chief, a Lion was surprised to see that the ant was working without supervision and he thought, if the ant can produce so much without supervision, wouldn’t she be able to produce even more if she had a supervisor. So he recruited a cockroach who had experience as a supervisor and was famous for writing excellent reports.

He needed a Secretary to help him write and type his reports and he recruited a spider who managed the archived and monitored phone calls. He also recruited a fly to manage the IT department.

The ant started to produce less work with the regime of paperwork and meetings which used up so much of her time.

The Lion came to the conclusion that it was high time to nominate a person to be in charge of the department where the ant worked. The new person in charge, the cicada also needed a personal assistant, who he brought in from his previous company to help him to prepare budgets and strategic plans.

Having reviewed the budgets and costs of running the ant’s department, the Lion found out that the production was much less than before so he recruited the Owl, a highly skilled consultant to carry out an audit and to suggest solutions.

The Owl spent three months in the department and came up with a glossy report that concluded “The department is over-staffed“. Guess who the Lion fires first?

The ant of course, because “she showed a lack of motivation and had a negative attitude“.

It’s a story I think some of us can relate to.

For me with coming from software development, such a tale is even more scary because of the potentially enormous sums of money that IT departments can simply swallow and also because IT done wrong can easily sink a company or at least greatly contribute to the sinking of a company. I have seen this first hand with a previous employer.

Regardless of your company’s setup, if your IT staff costs have ballooned or productivity has sunk what can you actually do? Slash R&D in which case you can be overtaken by the competition? Drop quality or reduce maintenance work, which will likely mean being killed by technical debt later and making your product worse, as well as killing developer motivation later as they fight a worsening code base? Or hire new staff to do the work because your existing staff spend all day in meetings, shuffling e-mails, writing reports, justifying budgets or their own jobs? And don’t forget to factor in ramp up time for new people, plus the related drop in productivity from your most experienced people who are tasked to bring the new ones up to speed.

Firing the ant is likely pointless and tricky too. He or she might have a large amount of domain knowledge and your software and systems are probably not that well documented. Also, firing one ant, might trigger the other skilled ants to leave as well.

I personally think that the building of empires needs to be strongly avoided in the first place, and efficiency and leanness need to be kept – difficult in large companies with an established culture I realise. If it is too late and you have large a large staff overhead that doesn’t add value or where staff are just no longer productive, throw away the book, restructure using lean processes, if staff aren’t and can’t add value, move or fire them, recapture a start-up feeling. That doesn’t mean everyone works fifteen hour days and lives off pizza, it means that everyone gets closer to meeting the needs of the customer, feels the urgency of that, does more with less and gets things done.

There is never a silver bullet for anything and everything is always work in progress, but here are are some suggestions around software development I’ve learned from experience:

  • Build teams that assume as much responsibility and self-governance as possible themselves and resist losing your top developers turning into project managers. Scrum is great for collective responsibility.
  • If you really need a project manager or scrum master, find one and keep your developers coding.
  • On the flip side, don’t let your techies become ants performing merely repetitive tasks, they might appear to be happy but inwardly be boiling with frustration and once they have enough time at your firm for their CV will be off to the next company
  • Also on the flip side, senior developers are often hungry for an official lead role on their CVs and might leave if that desire is unfulfilled. My suggestion there is nevertheless to try and keep your lead developers focused on technical tasks such as architecture and driving quality, and on guiding the team technically, and being generally hands on. It’s such an expensive waste to lose them in monkey work.
  • Seek out the ideas and creativity of your staff, imagine you are a start-up again.
  • Don’t shield your staff from the product and the company’s financial figures, or if your company is very large, your department or division’s figures
  • If you are the Lion, don’t shut yourself away from your team(s), sit with them regularly, talk to your people and get a feel for things. Don’t let people leaving be the only feedback you receive.
  • Cultivate a hands-on attitude, no-one in the technical department should be above getting their hands dirty, and purely administrative IT managers are an expensive luxury.
  • Look after your staff
  • Tear down communication barriers, don’t just communicate through meetings and tickets, scrum with its cross disciplinary roles e.g. dev, sys, DB, QA is great for communication

Interesting reading

http://www.slideshare.net/AmSam/the-ant-and-the-lion-rethink-about-your-… – a PPT of this story with images
http://en.wikipedia.org/wiki/Lean_software_development
http://www.slideshare.net/jpvajda/lean-software-development-principles
http://radual.com/what-developers-need-from-their-lead/ – Alexandru is a colleague of mine
http://www.dilbert.com/ – we want to avoid this world right?