How should my way of working change in an agile workplace?

Question

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

Answer 1

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! :)

Answer 2

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:

• Work in small pieces. You want to break your tasks down into pieces that can be completed in a reasonable amount of time. (The teams I've worked on usually measured things in half-day units. Thus you could complete 2 units of work a day, and 10 units in a week.)
• Commit functioning code. When you're working, you want to commit your code frequently, but only when the code compiles, and works without breaking your unit tests. You do not want to be the person who commits code that breaks a build.
• Write Unit Tests. Your team IS writing unit tests for its code, right? If not, then start now. Writing unit tests will force you to structure your code to be testable, which will also force you to improve your implementation and design. It will also detect regression errors, by checking everything that used to work when someone makes a change.
• Unit Tests for all bugs. Any time you need to fix a bug, first write a unit test that causes your code to fail in the same manner as the bug. Then fix your code. If the fix is good, your unit test should now pass -- and all of the rest of your unit tests should continue to pass.
• Unit Tests for all new code. When you're building new code, you should be building to a spec. One of the best ways to ensure that the spec is good, is to use the spec to write unit tests for your code. Once you've got enough tests to validate the code you intend to write, go to work, testing your code against your tests. Once your code passes the tests, you can commit to the team repository.
• Use Continuous Integration. This is something that the team itself should be doing, but if you can get the use of an extra PC (it doesn't have to be fast, just have enough memory and disk space to build your tools and build your software). Load CruiseControl.net or Hudson on it, point it at your repository, and configure it to wait for new commits, checkout your workspace, build your software, and run your unit tests. Why? Because it will catch when someone has neglected to commit all of the pieces of their change, before the change propagates to the whole team.
• Automate your builds. Before you can use Continuous Integration you need to be able to build your software repeatedly without human intervention. If you're using Visual Studio, learn how to build using MSBuild or Nant. If you're doing Java, learn how to build with Ant or Maven. By building automatically, you avoid build and release problems associated with manual steps. (I once reduced the build process for a project from a notebook that took 2 professionals a week to complete, to a set of scripts that would take about an hour to run -- you better believe that improved the quality of releases.)

Answer 3

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.

Answer 4

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:

• Huge change, or
• Incremental improvement

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:

• Try to deliver some software, or at least get feedback from the stakeholders
• Work out why that was hard and what you can do to make it easier.

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:

• Team not co-located ("Team" includes BAs and QAs)
• Environment not suited
• Lack of visibility of work in progress or overall goals
• Too much work in progress - things started but not finished
• Projects in progress that nobody really cares about
• Project progress makes it obvious that it's not worth doing
• Codebase is really hard to change
• Blame culture discourages collaboration.

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!

Answer 5

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:

1. Convert your existing project tasks/points/todos into User Stories
2. Pair program on everything. Switch pairs often!
3. Use Test Driven Development. Strive for 100% coverage!
4. Use one week iterations. Repetition is learning!
5. Deliver valuable software to the customer in each iteration.