Tag Archive | cerebra

tackling large projects

My team and I were recently made aware of the importance of aligning goals at the start of any project. Meeting our client’s expectations was essential to our success, unfortunately the vested parties were not always on the same page, which made steering the proverbial boat that much harder.

Communication and collaboration are such important elements. It contributes toward the team meeting all the relevant needs and achieving the desired end product.

While we managed to complete the project successfully, allow me to share a few core learnings in order for you to avoid ending up in a similar situation.

1. “On your marks, get set…”

It is essential that all teams are involved from the scoping phase of the project, else you run the risk of failing. If your client or the key stakeholders don’t provide input from the beginning, it will cause avoidable delays and most likely inflate the budget. Two things that are dear to any client; time and money.

It’s extremely valuable to have the entire team in the room when a new project is being briefed. Every person who has a vested interest in the outcome has to have a chance to provide input from the start.

This is a huge challenge because you will often hear, “I can’t make this meeting, so get things started and you can brief me in later”. Don’t let anyone do this to you! Find a time that suits everyone and ensure that they participate.

If a key piece of information is not relayed in the early stages it can cost the project ten times more work, cash or pain if picked up later.

2. Spend as much time as necessary making changes early.

Rather spend some extra hours early in a project to ensure that all your bases are covered. Consider the <a href =”http://www.agilemodeling.com/essays/costOfChange.htm&#8221; tilte=”cost of change curve”>cost of change curve</a> that is relevant when it comes to Agile development. It highlights that you need to make changes to a project early, while it’s still cheap to do so. The further you get into the project, the higher the cost to change your path.

3. Lot’s of talking

Frequent feedback loops are very important. Constant communication about progress, project tracking and obstacles, new developments etc. needs to be handled on a daily or weekly basis. This also relates back to ensuring that everything that has been finalised align with the overall objectives of the project.

4. Be honest

Recognise shortcomings or limitations. If you can identify any elements that will interfere or limit the ability to get the project done, then you need to address these immediately. Whatever the cause of concern may be, you will need to have the strength to confront these impediments and resolve them before they cost you productivity or delivery.

In summary, take time early on to align everyone’s goals, keep these as your compass throughout and always ask yourself if what you are doing meets the goals, make sure the team is being honest and, communicate often. If you can get this mix right, then your project is on the right track!

Advertisements

it is not the destination that matters, but the journey you take.

On our path to get the most return from our efforts at becoming Agile, I am becoming more and more aware of how daily improvements to our process are contributing to the overall success of Agile in our company.

Each organisation is unique, and importantly each team has it’s own objectives. Finding the right way for you is going to be key to making Agile work for you. Below are some of the concepts I have been trying to wrap my head around with our development team… (and if you have ideas, solutions or opinions, share them!)

Agile and Scrum aren’t friends

The essence of Agile is to be flexible and adapt to changing environments. Scrum methodology teaches us to protect the team within time-boxed iterations (Sprints) What I’ve learnt in trying to tackle unplanned work without interrupting the Sprint, is that Scrum can’t help.

We have moved towards using elements of  Kanban with our Scrum, whereby instead of blocking new work from being scheduled we now limit work in progress. There is provision on our planning board for unexpected projects and the team is able to accommodate these requests without stopping other projects. If no new requests come in, there is no idle time as each team member pulls tasks from other areas of the board to keep a continuous flow of work.

Roll over of tasks and points

Our team has started estimating effort points and this is awesome for me to get an idea of the scope of work required on a task. Trouble is, our projects tend to stay active for time periods longer than our Sprint. Therefore, I am struggling to measure the team’s velocity with Burn Down Charts (even trying Burn Up Charts) because a minimal amount of tasks move to “Done” within the Sprint.

We need to assess if we are pulling in too much work, are our projects too large, inadequately specified, or are our Sprints too short? There is visible completion of work (and a Shippable Product) at the end of each Sprint and actual effort points are recorded, only we have a roll over of ‘un-done’ which enters the next Sprint.

As Scrum Master, if I can work through these questions with the team and really clear the Sprint backlog for each Sprint, then we can even look at moving towards Release Planning!

Product Owners telling Stories

The most successful technique we implemented to get our Product Owners (PO) to increase their involvement with our Agile process was to encourage a ticket writing system. We showed PO’s a preferred format for writing a User Story and we now set up briefing meetings for new projects to work out the ins and outs together. This has helped team members better understand a project from a development perspective (got them wearing different hats) and it has helped the team with testing as we have a defined set of outcomes and expectations.

The continuous learning and real-life experience is benefiting the team and every day there is something that works and something that doesn’t. We get better as we progress and failing means that we know how to do something better the next time.

Look! It's paired programming!

Image via Wikipedia

scrum at a social media agency

When I joined Cerebra I was introduced to an agile process project management framework called Scrum. What I learnt trying to integrate Scrum is that, while the concept is simple, it isn’t as easily adopted and implemented. With ongoing attempts to integrate this into our teams, I have found that it takes perseverance, constant focus on the end goal and a lot of learning.

Scrum, as defined by the ScrumAlliance is an innovative approach to getting work done. It was originally formalised for software development projects and the evidence of how well this works is seen on a daily basis within our development team. Scrum provides a platform for people to work together effectively and relentlessly makes visible any problem that gets in their way. This way of working is based upon values of self-respect, respect for others, trust and courage.

One of my key challenges has been to apply the process to “non-development” teams – our content and community managers. Scrum’s foundation is built on the ability to be agile and adapt to any situation, so I have worked towards finding a way to ‘inspect’ and ‘adapt’ the process to find the value and appeal for the content team. Even though Scrum is designed to break down complex tasks, we have found huge value in collaborative daily stand up’s to promote overall quality and performance for all types of work. The team is able to support each other and find solutions to obstacles before they get in the way.

The things I have learnt on this path is that it definitely takes an invested team for the process to be effective. The roles people play are integral to success and everyone has to respect the process and understand why and how it can help. Only then are you able to start to see the benefits. What I have discovered, with much learning, tweaking and searching for quick alternatives, is that Scrum will work. It is not an overnight solution but a journey that you grow with every step of the way.

Watch this video to gain brief insight into some of the principles of Scrum.