Sooooooooooo! You want to implement Agile ja?
Ok first step, are we really aware of what is Agile, why is Agile right for me, how do I get my company/team on board and how do I make it fit our company?
In step 1 we are going to deal with: What is Agile?
The thing that we must first stress is that Agile is actually a collaborative term. In terms of specific methodologies, there are those that fall under the term, “Agile”. The important thing is that we understand what Agile methodologies are aiming to achieve:
- Team Empowerment
- Achieving Realistic Goals
- Frequent Delivery of Products
- Continuous Integration
- Steady Incremental Progress
- Cooperation between different departments and teams
Agile is a major buzzword in software development at the moment and rather than trying to follow the crowd, look at the above points and ascertain whether you have them, want them and/or need them. Most people would absolutely agree that the above points are if not beneficial in successful team based development, but essential. Let’s look at what each point really means.
Ok, what is team empowerment? A team of developers are employed essentially to complete new features for a system and maintain existing applications. Developers do this very well in principle, but as someone who’s job it is to make sure that the team of developers are doing the best they can, it is advisable to make the working experience as satisfying as possible for your team. Different people have very different views on what makes their job satisfying and it’s important to pay attention to each team member and with them, provide for their needs. This is not to say that you should pander to every team member’s whims and fancies, but you can certainly create an environment that suits everyone. One thing to consider is Developer Responsibility. Some of your developers will crave and earn more responsibility than others and this can be addressed very easily with Agile. For example, in your team you could have a technical architect, two senior developers, four mid level developers and 2 juniors. Where possible (don’t make up projects just to suit working roles, it’s all about organisation) you can assign levels of responsibility to capability, experience and developer attitude. The technical architect would naturally assume ownership of things like systems design and architectural builds. This empowers this team member by giving them something that while is not their sole responsibility, is hopefully appropriate for their role and aspirations for their working life. Give them that ownership and don’t micromanage them and you will often find that productivity and quality of work increases exponentially. The same for other team members with suitable tasks and projects.
I realise that you can’t always follow this, but keeping this in mind when dealing with your product backlog can really make a difference.
By including your team in decision processes for development of products will in a lot of cases, instil a sense of pride and team ownership of a product. Another way to increase your productivity.
Achieving Realistic Goals
In a lot of company environments, developers are inundated with requests, changes, demands and urgent fixes from different members of the company. Prioritising and project organisation can go out the window at this point and without something in place to keep perspective, goals and deadlines can spiral out of control. This can have a serious impact on work completed and team moral. Developers that are consistantly overworked and put upon with constant yet erratic demands will start to make mistakes and feel unappreciated.
By putting in place a procedure to deal with all types of requests can avoid the escalation of projects to an unmanageable level. By not setting your developers up to fail in this way, productivity, quality of work and moral is much more likely to improve. This also leads on to our next point….
Frequent Delivery of Products + Steady Incremental Progress
By keeping goals realistic and achievable, the delivery of products can have focus and team attention as well as developer ownership to really speed up the process in the SDLC (System Development Life Cycle). This has several effects. The developer feels a consistant sense of achievement, the product owners (who want the feature/system built in the first place) gets regular progress and completion.
Cooperation of Different Departments and Teams
Communication is key at this point, but that communication but be proactive and effective. Communication is to enable sharing of knowledge across teams, it’s also to spread the reponsibility of project and of course the more brains to solve things, are better than 1! The great thing as well is that different departments really get to know each other and what each other’s goals are. With a realisation and appreciation of priorities, overall prioritisation of products can be a much easier process. It won’t always be immediate, but with cooperation and communication, this can be achieved.
I realise that this is the last point on my list, but I feel it is actually the most important. I have one thing to say for it. The moment you start over complicating matters, you lose the point of the principle. We will be covering how Agile can be tailored to achieve all of the above while keeping a good focus on this.
So, is this the type of team/company/department you want to be a part of? You’ll notice that I don’t say “run”, the reason being is that as a team lead, CTO/CEO, department head etc, you are actually and always will be a team member, with your own responsibilities and role. That is extremely important to remember in Agile.
If so, watch this space for the next instalment of implementing Agile!