Agile officially rogue
Whilst software developers will tell you that agile, as a project methodology, has been around since Steve Jobs, it seems in recent times it has been gaining momentum across organisation wide processes. Agile now not just for the software development cycle is being adapted to workflow processes all around the corporate land.
The philosophical shift seems to be hinged on the downfalls of visibility straight up in a project life cycle. As any project manager knows all too well, a project is never all it seems at the outset no matter how much research is undertaken to know the ‘unknowns’. The reality is that all projects are inherently iterative and evolutionary. Requirements change, as a product becomes a more tangible reality. Suddenly, as it all unfolds you are building a speed racer when the functionality spec calls for a unicycle.
The most difficult part of agile is not the implementation, although it does requires a fundamental thought shift. The difficulty arises if an organisation is producing for a client. Clients without an understanding of the agile process will require education, to let go of the reigns and signing off the ‘fixed’ nature of a traditional waterfall project.
It would seem a dash crazy for a client to commit to an open budget, time frame and no known outcome. However as agile is implemented in larger organisations this is just the request. Rather sprints of tangible, launch able elements of a larger pie are created and all knowns and unknowns are handled in a smaller more containable environment.
The other quirk of agile is the involvement of the client. In my experience many of the heart aches of client, production relations rest upon a feeling of being left out and of not understanding the process. By taking a client on the journey, as agile requires, you are letting the client feel like an important, integral part of the team. This pays itself back a thousand fold. Realistically when things aren’t all roses and lemonade, the client will feel like they are part of the problem and the solution…when your on the same team it’s difficult to squabble and point fingers.
Agile also calls for conversation. The act of physically standing at a board, covered in post it notes screaming out points of the Fibonacci sequence can be quite a bonding process. It also allows every part of the team to be heard on equal and legitimate footing.
My agile role is usually the scrum master. Scrum is my preferred Agile development process. There is something satisfying about a small passionate team on the ground and running.
This can be split between project manager and scrum master however I find the two roles can often overlap. This can cause unnecessary complexity by providing for both. Preferably a good scrum master should be capable of the skills of a traditional project manager, such as setting up the project, tracking time and milestones.
A good scrum master is the conductor of the process, making sure the agile processes are flowing well through the team and protecting potential roadblocks during iterative sprints. It is an important shift that ideally there is no hierarchy in agile and the scrum master is not the boss of all. It is an inherent team framework working together. The scrum master just needs to keep the wolves at bay to make sure the work gets done, and that the team have everything they need to get it done. Essentially a scrum master is a project manager however working within the agile flavour.
The scrum master oversees product releases. Importantly each sprint should be a ship ready product. The release is made of sprints. Essentially you have
Product Back log // Which is broken into
Release Back log // Which is broken into
Sprints
Easy…