One thing I noticed (and it may just have been me) from the conversation was that the Agile team seemed only noticed when something was perceived to be going wrong – burndown not moving down or delivery dates slipping for example.
The subject of Overtime was one of the first subjects brought up. There is sometimes an expectation that teams should be working overtime. If the team is meeting its commitments it’s a question that should not be asked and there was a feeling that overtime should be a last resort – though there was an appreciation that business needs have to be paramount and there may be occasions that overtime is necessary.
Adding additional resources was also touched on. Again there seems to be a perception that all developers and testers were an equal resource and that just throwing more bodies at it would solve the problem. No consideration seems to be considered about the time upskill any new team members and the negative impact that “too many cooks” can have.
The group considered why overtime/additional resourcing might be expected. Too much work left in the backlog was one reason – 24 weeks of work left when 12 weeks till the project was due to end. This led to consideration of how such a scenario could happen.
Scope creep seemed to be a major concern – one example given was a rise in 300% from the initial backlog – and it is felt the onus has to be on the Product Owner to make the decision as to the value and necessity (such as legal requirements) of any additions in the prioritisation of the backlog. The Team does have a responsibility in communicating to the Product Owner (and so to the wider audience) what is achievable as the backlog expands via velocity and the backlog.
There was some concern that scope creep can arise as that a particular business area is worried that the team would only ever deliver the minimum viable product before moving to the next project and that they would never get the full functionality
Demands for overtime and/or throwing resources need to be countered with evidence. There are plenty of case studies that demonstrate the negative effects of continually working additional hours. There’s a great PDF Rules of Productivity from Daniel Cook which provides a starting point for this sort of discussion.
Another negative perception could be where observers start comparing teams based, for example, on velocities. A team with a “lower” velocity could be misidentified as not working hard enough. This seems to stem from a misunderstanding about how each individual team estimates its own work and that velocities should not be used in this way. Teams often seem to be assumed to be the same with no consideration made of individual differences or skills. If there is an issue within a specific team then that is for the scrum master and line manager to address.
Conflict also arises where the team are working in an agile style but the expectations and culture of the business are around a more traditional project management process. An organisation used to “Big Bang” releases may be uncomfortable with the Agile process and the perceived additional demands on time from the ceremonies. The lack of certainty over requirements mean Agile processes tend not to work well where Project Managers and the business are expecting to see a hardened Gantt chart.
This lack of certainty especially at the start of the project can be unnerving with an agile team only looking to refine the stories required for the next couple of time. The “Just In Time” estimates can make planning difficult especially as the team break down larger stories into more manageable ones as their understanding grows. A discovery sprint is always worthwhile with the team “T-shirt” sizing the full backlog to give an idea of the complexity and effort required of the project. An understanding needs to be made that this is only a finger in the air estimate and that this will change (no-one had an example of it decreasing) as the project scope is better understood over time.
Agile needs to be sold to the wider business as something to aspire to and the agile team do need to recognise that the business may not quite be there yet.
As an aside it was brought up that sometimes it felt that those complaining most could often be the greatest source of impediments! In this case the scrum master needs to push back on these impediments.
So what can we do?
Some solutions raised were:
Educate – if the development team is working using agile methodology they are well positioned to inform the wider business about agile working. We did a brown bag lunch on Agile – Agile in An Hour – presenting some of the core agile concepts to a wider audience. It also may worth suggesting (as has come up in previous Practical Agile sessions) more formal training for the decision makers within the business. In addition make sure the people who need to know what’s going on are included in reviews.
Pushback – in many cases problems always seems to fall-back on the development team. It must be remembered that it is the Product Owner who is accountable for the value delivered. They need to be aware of the impact of any new stories and make sure they are prioritised appropriately and that they need to be realistic about what can be delivered.
The team should also make sure any external impediments or blockers are raised and followed up to clear them as quickly as possible. The Product Owner needs to be in this loop in order to help the team and also that they are aware of external factors impacting the project as quickly as possible.
Be Realistic – Agile in itself is not the goal. The Business rarely cares how the product is delivered, just that it is! The team should work with the wider business on Release Plans and strive where possible to reduce the uncertainty as quickly as possible.