Dear MT listeners,
I am a big fan of the Develop a sense of Urgency in your team cast. I have applied it successfully in my previous role and I can confirm its effectiveness. Thank you Mark and Mike for the unvaluable recommendations !
I would need an equivalent concept for a different context : agile project, part of a significant change effort of the organization towards lean practices and employee empowerement.
As you may imagine, I ask your help because this change initiative does not progress ass planned, the team delivery is significantly below the expectations, and I think Parkinson's law is in part responsible for this.
Indeed, in this new approach, there are no intermediate deadlines, only the sprint timebox which is one month long. Furthermore, most tasks are not assigned to a team member, but they are rather part of the "team's" backlog, which make is virtually impossible to assign responsibility for a missed global deadline.
What we observe since several months now, is 20% of tasks do not get done, and that despite the product owner having lowered the bar in terms of requested features.
If you've had a similar experience, can you please share how you went about it?
Re: Sense of Urgency in an Agile Team
The whole point of Agile is to discover what makes *your* team more effective. It's meant to be more of an attitude about local performance improvement rather than a set of rigid processes and ideas that are expected to work for every situation. So it sounds like this below-expectations performance is your open door to take the team to more productive practices.
You've already identified several issues which are hampering effectiveness, and I think you could take your team through trying on different, more effective, behaviors, to remedy them. If they truly are embracing the spirit of Agile, then I would expect you could get them to try something new and monitor results without too much trouble.
If it were me, I would just say:
"Here are some things that in my experience will increase our performance. Let's try having each task have a single owner. And no tasks bigger than a week's duration--we'll break down tasks larger than that as needed. And shorter sprints: let's try 2 weeks so we can have more frequent retrospectives and speed up our internal feedback/learning cycle. If we try these things and they're not working for us, we can always try something else or go back to what we are doing now."
That last sentence seems to work wonders anytime I introduce change: it somehow takes away a lot of mental anguish associated with the permanence of new and different.
They may not like having actual responsibilities to meet their own task deadlines in the new world, so it may come up in retrospectives that "I don't know if this is working for us" artificially. It will be important for you to set the tone and remind the that "working for us" means that higher performance is being achieved, and not that "everybody is happy". As you know, there is *supposed* to be some stress associated with higher performance and a greater sense of urgency...it's about leading them from the uncomfortable stressors all the way through to the pride of accomplishment.
Good luck and please let us know what happens!
Several items to address here, separate them out ...
Given my experience with Agile teams over the past decade, I find that teams hitting plateaus like this can have many causes and can mean many things. Some plateaus come from team issues, some from issues nearby the team, and some very removed indeed. Some changes to circumstances take minutes, some days, some years.
What jumps out at me are these:
These are normal for organizations intending to change to make good use of Agile, but who have not yet "made the mental switch". At several months in, there's been several opportunities for learning and changing. Has that learning actually been realized as informed changes, which go in the desired direction?
The team is likely doing absolutely fine and is ready to make improvements. Private-mail me and I can help you speculate further. However, I believe you would be well-served with an on-site Agile coach for a few months, to help team and organization adjust and learn how to reliably improve.
Thank you for your feedback.
Thank you for your feedback.
We do have a scrum coach, who helps us put in place this new process and we have of course discussed a lot about this. And schematically his approach is to say that we need to give the team more time to come up with solutions by themselves.
My problem not only that we do not have this time, but most importantly I am not sure the team has accepted the problem. Indeed, the action plans the team has come up with in the retrospectives have been almost entirely directed to the outside : the backlog is not precise enough and the TPO requests too much from the team, the tools are not working properly, the colleagues in the test team are not fast enough to provide feedback, etc.
And while all this is certainly true, my "feeling" is there is also a lot of potential in the way the team itself works and how much pressure they accept to take. Especially that when we do not meet expectations everyone is responsible, but no one is identified in particular as not having done their job.
I had proposed to assign the complete sprint backlog (and reporting) from the beginning of the sprint, but this has not been accepted, since it is perceived as a non-agile approach. My other idea has been to declare myself integrator, and start defining a weekly integration plan. (at this point I have to say we are in a scrum of scrum context, with 3 teams working in parallel - my role is to support the global team achieve results - ~30 people) This second idea has been accepted, but it is not sufficient.
Thank you for your thoughts,
The Flaw In Scrum and Other Agile Software Development Processes
As I read your posts, the main problem seems to be that as you and your team adopted Scrum, you have measured a lower productivity output from the team. You and your teams are not unique in this aspect. Most agile software development processes, including Scrum, prescribe that the development team be self-organizing and self-managing. The dirty little secret is that this only works if the team has already developed excellent team management skills.
Most teams using agile or scrum that I have worked on or with have not had these skills. Most Scrum coaches and mentors will tell management that the team needs more time to “gel” when confronted with this reality. Rarely do they diagnose the exact problem and the cure. They convince themselves that the Scrum team, for example, will be better and stronger if they figure it out themselves. I have been on teams and worked with teams in this situation where we listened to the coaches and the teams worked six months or more without identifying the root cause and solving it.
I have come to the conclusion that, in this aspect, agile and Scrum mentors and coach are just plain wrong about affording time for the team to figure it out. Some will, but most will not. The way to get out of this problem while adopting agile or Scrum processes is to do the right combination of the following:
• Mandate the team plan iteration tasks that are no more than 16 hours and then hold developers accountable to deliver those tasks in the allotted time
• Ensure the team updates a visible burn down of the iteration every day
• Designate a principle engineer on the team who has responsibility for the technical viability of the work product the team produces
• Assign a software architect to the team who has architecture and design responsibility for the work product
• Have the development manager engage to facilitate the teams work, identify team management skills gaps and provide training to build team management skills in the team members
I realize that most agile and Scrum coaches and mentors will tell you that what I have noted does not comply with agile and Scrum methodologies. I am ok with that. I have worked on or with many teams that represent typical skill distributions and on every one of those teams where we switched to agile or Scrum, we experience the problem you appear to be experiencing.
There are a lot of other good comments here, so I will just focus on one detail. You said that your iterations are one month long, and Parkinson's Law is causing delays. That sounds like you need shorter iterations.
We started with two-week iterations, and they worked pretty well. But they were hard to plan reliably, and we had a lot of velocity variations.
We switched to one-week iterations about three months ago, and they helped a lot. It is easier to plan the iterations and the tighter timebox actually made our velocity more consistent. I think the short timebox has largely resolved the problem of Parkinson's Law, at least on a per-task level.
The key things we had to do to achieve the one-week timeboxes were to make sure all our user stories could be completed in less than two days, and to assign someone to update the daily burndown chart consistently so the team could see if they were going to miss their goal.
Agile Development vs Traditional Management Approach
Thank you for the original post. I have been going through a philisophical debate myself between pure agile principals as well as how to manage in that environment.
Overall, an agile mindset describes an environment that is willing to change to achieve the best output. The principals that govern this environment may include:
On the flip side, traditional organizations may have some of these values:
At the end of the day, these two approaches can achieve results. I believe that, these can also co-exist to some level. One struggle may be if the team does not meet a commitment utilizing agile, one must give the entire team feedback for not meeting the expected delivery. And another issue may be, if there are no deadlines, can you hold someone (or the team) accountable? I find that somewhat confusing philosophically.
What is everyone's oppinion on this? I'm interested to hear your thoughts.