The Public-i office has been extremely active lately, half the company has been taking up space in the board room for hours on end, whilst procrastinating where to put up our sprint board. You may ask what is a ‘sprint board’? – well this post is my attempt to give you a short and brief guide into our new world of improved product development and delivery as we deepen the agile development process and introduce a true scrum team and environment of software development.
As a technology company we need to continually show growth and expertise in delivering high quality product(s), with the emerging and diverse market and extensive, innovative research driven design work coming from the rest of the business, our products and technology division needs to adapt and react to the faster pace of change and expectation.
So, we are in the process of strengthening our existing agile product development in the form of a ‘scrum team‘, I (along with others) could talk for hours about what this means! but for now and for the purpose of this post I am going to briefly introduce to you what what that means.
So, in a nut shell and dummies guide I will try and explain it.
To start with we have expanded on existing roles and responsibilities by formally introducing a new set of roles that makes up the scrum team:
Product Owner: Visionary and owner of the product roadmap
Scrum Master: Organiser & coach to the team to ensure the sprint is delivered
Team members: The main doers, a combination of UX and developers
The team will work collaboratively using an edited version of the ultra successful lightweight methodology and framework design process of scrum to implement our complex products and software applications. Public-i’s vision for the future means we need to grow on our existing agile product development process, this will also allow us to be more reactive to user and client needs whilst granting us quick and frequent new feature deployments and reacting to known or reported bugs.
The idea of a ‘sprint’ means the team (above) has a strict timetable of events that determine the sprint cycle with the cycle being continuous:
Sprint Planning (adding stories and tasks into sprint) >
Daily Scrum (daily stands up to inspect and adapt during sprint process) >
Sprint Review (meeting for anyone to inspect and review what has happened during the sprint) >
Sprint Retrospective (meeting for the scrum team to review and adapt what has worked during sprint) >
So, you ask, this all sounds very exciting and positive, but we want to see results, as Product Owner I will be sending out regular update emails and posting more on here giving clients (and users) a more transparent representation of current deployments and feature updates. And of course I will continue to present at the next user groups next to be held in June.
For now all I can do is promise that we intend to react and deliver client and user defined iterations at an increased level and velocity. This is an exciting time for us and we are looking forward to our new world of design, technology and change.
