go A phrase I’ve heard a number of times within enterprise organisations is a confident statement of ‘Oh yeah, our teams are all Agile’.
This generally fills me with dread, given my experiences of Agile adoption in enterprise organisations. In general is covers up a lack of understanding of what Agile development is about or worse a lack of understanding of what the team is actually doing. My biggest concern when I hear this is that the team has stopped trying to improve it’s processes and has dropped into a sub-optimal cycle because it is easy.
I discourage managers from making outright success statements like this as it can result in the team stopping looking for improvements. Instead I get them to focus on rewarding and praising teams for displaying behaviours which link back to the Agile manifesto and are focused on improving the development cycle.
source url Retrospectives
A key meeting I try to always attend is the retrospective. This provides a good insight into the behaviours the team is displaying and to whether they have dropped into an overly comfortable cycle. I will keep an eye on whether the ideas are really focused on tangible improvements and ensure there is a good mix across the whole team.
I also use this as a good opportunity to remind the team of the medium term goal – Which can feel a bit like a Big Hairy Audacious Goal at the time, but ensures everyone remembers that they are on a journey towards better Agile delivery and haven’t yet reached the destination.
where to buy atarax Performance Management
Most enterprise organisations have some sort of annual appraisal process. Personal goals are set, regularly reviewed and then linked to annual bonus, promotion and/or payrise processes.
Traditionally goals are focused mainly on ‘What’ the employee has achieved and less on ‘How’ they went about achieving it. For technology professionals this can result in goals such as ‘Delivery X functionality by X date’ or ‘Ensure all Project Milestones are delivered by X date’. I have also seen situations where the only benchmark used to measure a development team was whether they delivered within 10% of the date they originally committed too. These types of measures reinforce Waterfall values and can result in poor behaviours such as cutting quality or ignoring usability.
In an Agile environment I believe the focus should be more on how regularly the team is delivering value to the customer and should encourage continuous improvement in process. Ideally the team should be given commercial business outcome related goals, which given them scope to define exactly how they are achieved and require everyone to consider the commercial impact of the work they are doing.
How do you keep teams focused on continuous improvement? Leave a comment to share your ideas.