Hi,
In my workplace, we "follow" the agile methodology. However, all we do is standups. How else do I have to change my way of working as a developer, to follow agile?
Thanks
Hi,
In my workplace, we "follow" the agile methodology. However, all we do is standups. How else do I have to change my way of working as a developer, to follow agile?
Thanks
That sounds like waterfall with daily meetings. Implementing agile is quite a vast difference and you can't just change from waterfall to agile yourself, you need others to follow suit for it to work.
I think the largest change will be to stop thinking in "project" scope, and start thinking in very small increments of work. For example, when the project "Create website X" comes up, you'll need to break that down on a page by page basis. Determine what needs to be done, how exactly are we fetching, storing, updating, displaying the data. How long will it take to write the different pieces of code required to do that? Once that is laid out (there is much more planning involved in agile, from my experience) then you can start saying "By Wednesday, I'll be able to show you guys that I can save on page X and I'll display the data on page Y".
Usually there is a "planning" meeting. This can take an hour or it can take 6, this depends on how well your criteria is conveyed, how many members are on the team, and how long of a sprint you're working with. Everyone selects work that they will do, and puts estimates on it. After your sprint (which most people recommend to be one or two weeks) there is another meeting. Ideally in this meeting everyone will demo what they have been doing the past week(s), and it will work perfectly. Afterward there is some reflection, what worked well? Did we mis-estimate something terribly?
That is one "cycle", do that ~50 times and website X is complete! :)
Agile is really a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. It's hard to do by yourself.
That said, there are things you can do that will make you more agile, and that your teammates may choose to emulate once they see the advantages:
To start with, there is no such thing like "the agile methodology", agile is an umbrella term that describes several agile methodologies and if all your workplace is doing is standups, I can already tell you that this doesn't make a workplace agile.
Second, while you can adopt some "agile practices" (especially engineering practices) at an individual level, this will never be enough to make you agile: 1. agile is in my opinion more about the way to drive product development than engineering practices 2. agile is a collective team game.
So, my recommendation would be to dive into for example Scrum and XP from the Trenches and to grab some copies for your coworkers, your boss or potential sponsors.
Congratulations on doing stand-ups. It's a good first change.
That you're asking suggests that you or the team would like to be better at this. In that case, you can go one of two ways:
If you decide you'd like a huge change, you'll probably need some books, training and maybe a coach or experienced practitioner around. This is often successful if people higher up in the organisation are invested in the change too.
If you decide you'd like to improve incrementally, it's worth reading around Agile just to get some ideas. I recommend "XP Explained". There are a lot of blogs out there, too, as well as posts here. The two things you'll need to do are:
We normally do the first with showcases and the second with retrospectives. I recommend having retrospectives at least every two weeks, even if it's really hard to showcase working code.
Things I often see flagged up quickly as problems include:
Whatever you find out, you won't be the first.
Note that Agile is a transparent methodology, whichever version you use. A lot of people get scared by transparency. This is normal. Sometimes managers higher up have a vested interest in not allowing things to be transparent. This is also common, and at that point you might need external help. Delivering working software can be very persuasive, though.
Good luck!
If you want do to this from the ground up, then all you need is the agile manifesto and recurring retrospectives each week. But I guess that is not enough, so here is my start-up-list: