Starting an Agile Project | BJSS

    By Marzena Jagucka, Shasheen Roberts, Lisa Harris and Phil Kennaugh, Delivery Managers and Business Analysts

     

    All too often, Agile projects are initiated with the best intentions, only for teams to fall back on Waterfall (or worse) procedures for set-up and configuration.

    Starting an Agile Project, an interactive event, provided an open forum to discuss issues surrounding Agile project delivery with our team of experienced Delivery Managers and Business Analysts.

    During the event, our hosts introduced the areas they encounter most when delivering an Agile project. Using interactive breakout rooms to discuss each one in more detail. Participants were encouraged to join in and encouraged to ask questions and share their own experiences. The breakout rooms allowed attendees to uncover a deeper of understanding of some of the key issues with an Agile project.

    Below, each of our hosts talk over various areas such as: stakeholders, knowing your team, starting a small project and some key Agile methodologies. They covered these topics during their talks which took place in the event and shared some of their best practices guidance for starting an Agile project.

    Marzena Jagucka

    For many enterprise-scale Agile projects, there are lots of hoops to jump through. From internal sign offs to project governance – there can be a raft of bureaucracy that can hamper the velocity of Agile projects. To combat this, identify your key decision makers and stakeholders from the outset and start to build a relationship with them. They will be important in helping to move the project along. When communicating with decision makers and stakeholders transparency is key. An open dialogue must be conducted throughout the project, so everyone is aligned. It is also important in communication and understanding the difference in stakeholders’ levels and their expectations in terms of being provided updates.

    During the event, we went through various Sprint Zero activities including the importance of knowing your team, developing a common understanding of the goal and the Minimum Viable Product (MVP). We also shared some best practices and ideas for you to try when setting up a new project. We outlined a couple of examples, including self-serve reporting and the different levels of planning in Agile (release, sprint daily).

    Shasheen Roberts

    During the event we covered documentation and explored the common thought that Agile means no documentation when, in fact, it is prescribed documentation where necessary. We also talked about senior stakeholder needs and how to manage their expectations to understand when something will be delivered versus balancing the team’s Agility. Finally, we touched on how story points are personal to a team yet are often used to measure general progress.

     

    Lisa Harris

    In my group, we touched on a variety of areas - from getting started through to obtaining buy-in from senior stakeholders. One of the key themes in the discussion was - how you go about using any framework to deliver a project when your directors do not believe in project management/delivery management approaches? We shared some best practices for getting Agile projects up and running, including starting small and why this is more important than jumping in the deep end with a project which is not too high profile but is somewhere in the middle of the company agenda. In addition to this, we stressed the importance of getting a team together, which is made up of like-minded individuals.

    We highlighted the need for a product owner from the business who can provide direction towards the end goal. Once you are in the flow, you can then present the story to the directors highlighting successes, how you are adapted if something did not work out and how the agile approaches used benefitted the way the delivery went.

    Phil Kennaugh

    Within large organisations, areas outside of the technical delivery teams can be hugely siloed and bureaucratic. Some examples raised were legal and procurement. We examined creating a broader ‘cross silo’ team with representatives from external functions attending planning sessions, demos and retrospectives, as a pseudo’ cell (‘Collaboration Groups’). The SAFe methodology could also be used for larger planning sessions across multiple teams. This helps to co-ordinate activities and explores the value of demos in showing other silos the benefits of shorter and more frequent delivery cycles.

    Lastly, we discussed how large, unwieldy governance structures could be made significantly more efficient through having a single, empowered Product Owner, preferably with control of the budget.

    This creates an air gap’ between senior decision-makers and the delivery team and removes delays in getting agreements if the PO' is empowered to make the call in the first instance. One of the attendees in our breakout room works for an organisation with this flat structure and a PO role, which was a useful case study.

    Enterprise Agile - Download the eBook
     

    Since we were founded in 1993, one of our core values was a total focus on delivery. In pursuit of this continued vision, we’ve dedicated a great deal of effort to discovering what works, and what doesn’t, when designing, delivering and maintaining enterprise-scale systems.

    The Enterprise Agile Book is a distillation of years of our learnings, written by our experts from delivering industrial strength software for clients in some of the most complex environments.