How do you foster the “We’re all in this together” ethic to ensure the team does all it can to complete work.
One of the challenges faced from agile teams has been around how the business perceives the work that the development team are doing. This can lead to a disengagement on both sides, with the business saying that nothing is ever delivered on time and the development team feeling that they are being set impossible tasks.
One of the key factors discussed in this session was around that relationship with the business as being the critical point. Those of us working on projects know that the teams generally are working as well as they can (and in a agile way, they should be with retrospectives and the like) but the measurement of time against these projects takes a lot of the good the team are doing away as finished products are what the business ultimately want, they want those new features to grow their respective businesses and they want them as soon as is possible.
This, from the discussion is, something that most people had experienced in working in an agile way at some point. A lot of the time the teams were faced with a “worst of both worlds” scenario, where the business wanted very light up front requirements as per agile, but wanted the perceived certainty of a waterfall projects delivery date.
This inevitably leads to one of two things or quite often , both:
- The business take the hit: They do not get what they wanted, when the wanted it or the project scope is reduced and/or
- The team take the hit: You end up “crunching” your team, adding resource in the hope this will pull the delivery around
We will be looking at the options around projects and what can be done in another blog post as it’s a whole subject in itself, but for now the key take away points were
- Avoid “Death Marches~ A “Death March” is a project that for those doing it, is destined to fail or require significantly more time than was originally proposed. One of the key ways it seems to prevent team engagement on a project would be for a business to impose deadline and fixed resources on a project, without anyone from the project actually being aware of what the project is or being able to feedback concerns to the feasibility of the project given the time and resource.
Fixed deadlines are a reality of Software Development, business tend to want to plan and need projects done for growth or regularity reasons by certain points in time. However one way to prevent the death march discussed was the use of a Discovery Phase where the team spends time before a single sprint is done in order to work with the business to see what is required for this project and when, to help with the future architectural decisions and to find most of the “known unknowns”.
Once the team has done this they can then feedback to the business to give them an idea of what can be delivered and when, given the resources and complexity of the project. I realise that this is not by any means, pure Agile. Agile does have a concept of Sprint Zero, however whenever you use the words sprint to the business they expect some kind of velocity to be tracked against it. Starting out a project already behind is not a great way to go on.
However, this is a blog around practical agile and about how to work in the real world when your company still has a vested interest in a non-agile approach for project management at a higher level than the software delivery team.
- Trust us. The business need to trust the teams when they say what can and can’t be done in a given time. This is a big ask, particularly if you have a track record from the businesses perspective of not delivering on time. However moving to a more frequent delivery cycle as per what you should do in Scrum for example will help as the business will see you delivering value and trust your recommendations more.
- Product Owner in the team. I some instances on projects product owners have not been fully within the team on a day to day basis, maybe just being seen around Sprint Review time. Business that have changed this relationship and had embedded or employed full time product owners have reported much more understanding from the business around the delivery of products and an increase in trust between the business and the team. The products owners are great at communicating with the business and this leads to a better understanding of what can and can’t be achieved by the team to a wider business audience.
There were other things touched upon, in this discussion and some really good idea and solutions came out of it. It was particularly good to hear other people s views about this common issue and what they have done to alleviate it. Of the people round the table I think all had come across this before but their current companies had addressed this using some of the techniques above.