Thursday, March 15, 2012
In my experience finding agile work isn't that different than finding any other software development job, but your success will be on how much preparation you have done beforehand.
So why would you want a job in an agile software company?
The answer to this is a post in itself, but some of the major points are:
Self organizing teams rather than micro management - teams are given a vision, direction and goals, but how they work together is up to them within those boundaries and that of the agile framework they are using.
Sustainable pace - rather than having times when you are pushed to the limit and times where you're twiddling your thumbs, agile companies promote working at a pace that isn't too fast or two slow and at an even rate.
Rapid feedback cycles - teams work in short iterations/sprints where they'll produce working, valuable functionality. These are 1 - 4 weeks in length (2 weeks is the most common). During this cycle continuous feedback to the customer or customer proxy is recommended. The team also gets together once a day to talk about what they achieved the previous day and plan what they are going to do that say. At the end of the iteration the work done is potentially shipable/releasable.
Continuous improvement - teams are encouraged to always find ways to improve themselves. This is usually through using retrospective techniques at the end of a sprint/iteration.
Trust - self organization is one part of this, but also allowing the team to set working hours and when they come in and leave. Teams are asked to do a certain number of hours during the week, but it's up to them to set those hours. After all, we are adults.
The use of techniques such as TDD, BDD and Continuous Integration.
Be prepared to answer this question.
Before getting your CV/resume out there, there are a number of steps I'd recommend.
1) If your new to agile, read the Agile Manifesto, understanding the valued and principals is essential. A good place to start understanding it is here:
Also research the different favours (XP, Scrum, Kanban, etc.) and research the techniques and technologies used by agile teams. Some essential ones are test driven design, behaviour driven design, continuous integration and pair programming. Not only research but try out some of these on your own.
If you're experienced with agile, I'd still recommend continually researching new techniques and practices.
2) Get involved with a local agile group. This will allow you to build relationships with other agilists, but also listen to what they say about their own companies. Some of these companies maybe worth direct applying to when you're ready. You may also hear about open positions from other members, but not treat this group as your own personal recruiting circle. Without building a relationship first, you'll just alienate people by continuing to ask.
3) Improve your internet presence. Companies who are passionate about agile look for people who are equally passionate about it and software development. I'd recommend starting a blog. If your new to agile it doesn't matter, just blog about your experiences with it so far and blog your own experiments with techniques like TDD. It doesn't have to be all about agile, so write some posts on your core strengths too.
Blogging is only one way to improve your internet presence, engaging with other agilists on social networking sites is another. Join Twitter, Google+, Facebook, LinkedIn and start talking with others.
Here are some people you may want to follow:
After you've prepared yourself. Now it's time to:
Find a position to apply to
Hopefully by now you've started to build your network. Your network is the best place to start looking for an appropriate job. Not only will you get some inside knowledge about the companies you're applying to, but usually if someone has put your CV/resume forward you'll get an interview. This is because people generally won't put people forward unless they think they will do well.
The downside of working your network is that positions aren't always open. With that in mind, your next option is to find a good recruiter.
For my last two positions I used recruiters and found good agile companies to work for. One thing to do is make sure the recruiter knows that you're looking to work in an agile environment. This will dictate the companies you you'll be put forward for. If a company passes you over for an interview, ask the recruiter why. This is valuable information so learn from it. You may need to change something about how you apply.
Finally if a company likes your CV/resume they'll bring you in for an:
There are a good number of companies that pay lip service to being an agile, but there are also a good number that are passionate about it and they look for people who also have that passion.
The interview is as much about you interviewing them as it is about them interviewing you. Use this time to try and understand how they practice agile and their understanding of it. I'm going to assume that you've been for a technical interview so I won't go into this in depth, but some questions you may want to ask are:
Can you describe your agile process?
How do you deal with technical debt?
What are your company values?
What suggestions would you make for people looking for an agile software development job?
Friday, March 9, 2012
At my new company the common practice is to invite the Product Owner and any interested stakeholders to the end of sprint retrospective. When I first heard this it surprised me as I've always believed that the retrospective should only be comprised of members of the development team. The reason for that being that the team may not be comfortable discussing some things with those outside of the team. It's essentially a safe place to discuss issues. As a ScrumMaster, the only times I've allowed managers, product owners etc in is if they are also members of the dev team. That said if a team is truly happy with others being there and vote to include them, who am I to say no.
When I brought this up with my manager, his counter point was about transparency. If the team feels that they need a safe space then there's something wrong.
I can definitely appreciate that as I always try to surface conflict and promote open discussion within the dev team. I'm also a great believer that transparency is crucial. Talking about issues behind the PO's back goes against what I'm trying to do with the team. That said having the PO at the retrospective can drive conversation underground when there is conflict.
What are your thoughts on the subject? Do you include people from outside the team in your retrospectives? What about transparency?