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” 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!
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.