For the last three years, I have been implementing Scrum methodologies in the companies I have been joining. A couple of years ago I joined a company that was trying to rewrite its e-commerce website for a year and a half. Applying Scrum and shuffling the team to have the assets we needed to build the platform, we rebuilt it in 4 months. It’s anecdotal of course, but I think Scrum can work marvelously with the right technology and mindset.
And for me, it’s not really about Agile. I don’t care that much about Agile; I care about building the best products, the most efficient way possible. Scrum filled that gap for me in a world of processes despair.
As I joined bigger companies, I have been surprised to find Agile often having a stigma; I heard things like we have to follow a strict roadmap here. Every design, UI workflow, needs to be approved before starting development here. I have been taken aback by those comments. For me, Scrum is really about how we handle development in the team efficiently and clarifying what we are building before we are building it. Making product development just a bit saner.
I think we can provide a very strict roadmap, get designs and workflows approved before the sprint, in fact, we can adapt Scrum methodologies so that for the world outside of the Scrum team there is no real change in the processes.
Like my Agile coach once told me, project estimates are always wrong, scrum estimates are just a bit better because they are at least based on an empirical process.
Will scrum expose flaws in the spec and UI provided? Probably, at least now you know, and as the ScrumMaster you can work at improving that. It is important however that the dev team with the ScrumMaster to be in charge of the team processes.
But it seems a lot of companies have been burned by the Agile ‘sectarian’ way of doing things and can’t think about applying new processes without being caught up in the whole debate about if what they are doing is Agile. Companies want their employees to be more efficient, if they can be happier at the same time, well there you go. However, if you are going to disrupt every other department with Agile or your strict Scrum processes, nobody is happier, you will be creating more tensions in the company. Not all companies want to do the whole Agile Company thing.
I think some Scrum masters are making a bang up job at managing scrum outside of the dev team.
Then again, maybe it’s because I have not been part of a company where Agile is the mantra of the whole thing but I never been inclined to shove my processes to everybody in the company, I just want my teams to deliver better products and have fun doing it.
Lately, I have been thinking about what is the processes foundation I try to implement.
Yes, there is plenty to debate here, first, is using ideal days. Some of you may scream at your computer right now. Hated because time estimates can get out of hands if taken literally in time (which managers tend to do), I see’s it as a complexity system. Having tried story points relative complexity and ideals days, I find using ideals days tends to be more precise over multiple sprints.
Also since you can do a percentage of efficacy, it makes it easier to find and work on issues outside the sprint items that were slowing your team down. Example A team with five developers with a percentage of efficacity of 60% should have a velocity of about 30 points. Understand and investigate where that 30% is going, is it just bad estimates, are you missing QA resources or maybe the build process is not working correctly, etc. You never will be at 100% because of meetings and life, but you can certainly optimize it.
But that’s just half of the story. This other part is to use technologies your team know well and make them productive, and that part is just as hard.
Source link
