This post originally started out as a mini-tour through a few of the agile methods that could be applied to systems management teams, however I’ve decided to turn it into an ongoing series of posts as one would end-up being an almighty essay – look out for Part 2 on Retrospectives soon!
Agile Systems Management?!
In the software development world, the agile movement is nothing new – it has been used within various organisations around the globe, and is rapidly becoming the de facto methodology for founding and transforming development teams.
However, expanding that set of practices into systems engineering is most often overlooked – sometimes because systems management can be overlooked in general, and sometimes because it’s “good enough” to not warrant attention. With the emergence of DevOps, systems engineering is now getting a lot of much-needed attention – adopting new tool-sets, landscapes and practices, so it’s now more important than ever to give your systems teams the support they need.
Being “agile” doesn’t necessarily mean that you have to adopt every part of the philosophy for it to be useful – far too many teams end up swallowing the entire agile manifesto and changing too much, too quickly. There are some practices that can be introduced independently of each other, at different times and different speeds, and one of them is stand-up meetings.
Provided that it is done carefully and for the right reasons, Agile can make a huge difference to your systems management teams, from support all the way through to project-based consultants, and the easiest process of the lot to implement is the stand-up.
The Anatomy of a Stand-Up
Stand-ups are short daily meetings usually held each morning. They can exist in any context, either as a smaller sub-team or part of a larger organisation – however attendee numbers should be kept minimal, and the aim is to conclude the meeting before people get restless.
During the meeting, each member of the team gives a snapshot of what they are currently working on, any problems they’re having, and what they will be working on next. It’s that simple! Any more complex issues raised at a stand-up should be discussed away from the meeting, so that the meeting itself doesn’t drag on.
Beware though – the stand-up is not a recorded meeting, and no notes should be taken. The best rule is to remember to talk to someone about anything you find interesting after the meeting.
After a few stand-ups, the team should be able to quickly get a sense of what progress is being made, and everyone should be able to tell someone else roughly what another team member is working on.
Often when you have several teams running stand-ups within an organisation, it may be a good idea to have a secondary stand-up at another time of the day (for example, after lunch) where representatives of the smaller teams gather to give an update on behalf of their team, taking the principle of team-based knowledge sharing and turning it into a cross-organisation progress update.
Putting it into Practice
Stand-ups ensure that everyone on your team is communicating regularly about the things that matter, are possibly the easiest of all the agile methods to adopt, and arguably have the most tangible benefit: shared context.
If you are managing a multi-skilled team of specialists, it helps if all of those specialisms are being utilised.
Bugs could theoretically be caught early, a fresh perspective on a problem could help the team fix an issue a lot quicker .and projects could run more smoothly due to the shared information within the team.
For a more support-oriented team, stand-ups can be trickier to hold as work tends to be reactive, however any larger ongoing requests can be discussed, enabling your engineers to help each other to remove blockers and get feedback to stake-holders more quickly.
For the larger “stand-up of stand-up” meetings, this has a great effect on your organisation’s atmosphere, enabling business units to communicate much more easily and share both upcoming projects and issues they are currently having, allowing others to react and adjust their own plans – for example if a project or issue is taking longer to complete than originally estimated, it can be mitigated, reprioritised or rebudgeted.
In short: stand-ups are great, try them for yourself!
Feel free to ask any questions below in the comments, and don’t forget to check out the many resources on agile methods already published, including this great post from the Scrum Alliance on the mistakes not to make when running stand-ups!