Agile Wars: The Team Awakens
The moving car is your project you want to develop. The road closed is an obstacle you may come up against. A truly Agile team is people who have an overpass or emergency by-pass and set it up.
Nip, tuck, and tailor!
If anything, Agile methodology is about continuous improvement and flexibility. So customize and tailor it the way it best suits your organization. Large-scale operations? Well, then you cannot have daily stand-ups with 40 people churning out their status reports: make it a quick summary, a scrum of scrums, or even an email shot. An Agile coach told you to use a whiteboard with Sticky® notes just because people are tactile and enjoy a sense of achievement by re-pasting a note from the “In-Progress” lane to the “Done” one (plus, brownie points for progress visibility with senior management)?. Maybe. Or maybe, an electronic Kanban board could do just the same, and eliminate waste and actions with no added value? Bi-weekly sprints? Some companies do one-week sprints, or even 4-week ones (even though you might be accused of doing iterative Waterfall rather than Agile.
Consider setting up a Kanban board, or even use a combination of Scrum and Kanban – ‘ScrumBan’! Do what works best for your team.
Our team members at NIX Solutions never forget that with 2-week classical sprints the QA engineers feel pressured to complete testing by the end of a sprint, which may ultimately result in subpar quality of outgoing builds. Always keep reminding developers that both new features and even a minor change may involve a considerable amount of QA effort. Make sure that you do not overcommit in terms of what goes into a sprint just for the sake of team velocity, and leave enough hours, or story points, for QA side of things. Work out what’s best for you, and tailor, tailor, tailor!
Make sure your sprints align with the product development strategy
Make sure that the mission-tactics-operations paradigm is well-oiled and in place. If your operations team is happy with the app [delivered by your Agile team], and tactically it is all going fine, i.e. user stories are accurate and business-validated, etc., but there is no underpinning long-term product development strategy that trickles down from the company’s mission into development sprints, chances are you are going fast. The trouble is that you are going in no particular direction.
Adjust the sprint’s length to suit your environment
If you deliver monthly versions or releases, consider syncing up your sprint’s default two-week length to the actual delivery date, i.e. making it a 4-week sprint. Testers will have enough leeway, team members will feel more pressured towards a real-world deadline, the project’s milestones and priorities will get a better alignment, too. Do the sprint durations that work for you. Never go for cookie-cutter solutions.
Think users, not just developers
A curious case of a US multinational curtailing its 2-year Agile project to the very basic functionality was recently discussed by the community both in the US and Australia. Millions wasted, the sub-par app delivered. Reason? It never dawned on the development team to get a UX professional on-board, because, wait for it, ‘UX designers are not part of Agile teams’. When the end-product was finally rolled out, the target users, no surprises here, flat out refused to properly employ it because it was too difficult and non-intuitive to use. Have a user-experience professional or customer advocate on board, even if for a short-term contract, to lay down the foundations. When the project is in full swing, with 50% of code done and dusted, it might be too late.
Leave retrospectives with crystal-clear follow-up items
Nothing de-motivates a team more than leaving a retro meeting without real-life follow-up items that would help everyone run the project more smoothly. Except for having those follow-up items, and never delivering: make sure that each item is assigned an owner, and a tentative completion date.
At retrospective meetings, always check with the team the progress of action items they had committed to. Seeing the feedback incorporated will energize your Agile team-members a lot better than any of Scrum Master’s pep-talks.
To segue into some of the life-hacks we use at NIX Solutions: consider including the retro’s action items in a tracking system of your choice, be it JIRA, Trello, A-ha, etc. Not only would you make sure nothing falls through the cracks, but you will undoubtedly gain more traction with any customer because a fair number of retrospective follow-up items deal with process improvements – something that directly affects both the customer’s financial bottom-line and team’s overall morale and sense of inclusion. And one does not want to pass up on that chance!
Don’t miss the last part of the “Agile Wars” coming out next week!
