Standups offer the most benefit when they are kept brief (30-60 seconds per team member) and to the point––sustaining communication about the state of the work. It helps when team members know the questions ahead of time and come prepared to answer them succinctly.
In December, Debbie Madden, from Stride Tech, interviewed Diana Larsen and Ainsley Nies, the co-authors of Liftoff: Start and Sustain Successful Agile Teams. Debbie called Liftoff (the first edition), “one of my all-time favorite reads.”
Calling all testers and QA focused team members! Have you wondered about how your work and perspectives fit in James Shore and Diana Larsen’s Agile Fluency Model?
Listen in as Diana talks with Mandy Ross of Sococo about the learning process. Part of the Agile Amped: Inspiring Conversation series.
At the Agile Open Northwest Open Space event, Diana Larsen led some discussions about the utilization and evolution of the Agile Fluency model. Afterwards, Diana spoke to InfoQ about her involvement with and contributions to the Agile community over the last 13 years and the fluency model.
“Agile just isn’t working for my team,” Arno said. “My company decided to go Agile six months ago because we needed faster delivery, and now my team won’t even tell me when they’ll be done with the new application. They say they can’t because now they are ‘Agile’.” We could hear his air-quotes over the speaker phone connection. As we listened to our friend Arno complain about his workplace, we looked at each other. We were mentally tallying all the misunderstandings about Agile that his comments reflected. There were so many, we wondered where to start in helping him get a better handle on his situation.
There’s this thing…as Jim (James Shore) and I have mentioned before, in the early days of Agile we would visit teams and hear, “This is the best job I’ve ever had. I love this work.” People who were doing Agile (usually Extreme Programming) were excited about it, they shared it with others, who did it, and got excited. But at some point, someone shared it with someone who got excited about it and shared it but didn’t DO it, so their sharing lost a bit of fidelity, like a copy of a copy.
How do you set conditions for organizations to become “learning organizations” and how do you support the self-organizing teams that emerge from this transformation?
As a leader in your organization, you want to do everything you can to ensure the successful results of your work groups and project teams. You know that investing in a great beginning pays dividends as the work continues.
Steve Berczuk writes a short and succinct article on TechWell describing, “Why Agile Retrospectives are Important in Software Development.” I’m looking forward to reading the comments and responses he gets.
More and more I think of Agile Retrospectives as an opportunity for the kind of learning that leads to real adaptive action in complex situations.
Many leaders focus on improving productivity and performance. Leaders who support regular retrospectives gain an effective organizational learning tool that guides project teams (and ongoing work groups) to reflect on their technical, human and organizational systems that affect performance. A well-facilitated retrospective gathers together significant project stakeholders (including the development team members and other critical players) to review their project experience, learn from the experience, and take action to improve - in the next iteration, the next release, and for all future projects.
Does your organization utilize retrospectives as part of its project management goals? If not, here are some simple...
Every time I ask about team’s challenges with retrospectives, a recurring theme comes up: Acting on Actions. I hear, “Our team doesn’t follow through on our plans for action.” Or I hear, “Our team never identifies improvement actions.” Both are retrospective “smells.”
Diana has written previously about the Human Systems Dynamics Institute and their excellent program that provides models and methods for dealing with our VUCA (volatile, uncertain, complex, ambiguous) world of complex adaptive human systems. In this post she focuses on the HSD Adaptive Action model and its unexpected connection to retrospectives:
In 2006 Esther and I introduced a Flexible Framework for Agile Retrospectives, a series of stages for designing effective retrospectives: Set the Stage; Gather Data; Generate Insights; Decide What to Do; and Close the Retrospective. We recommended a recurring cycle of retrospectives after each iteration as a process for the team to "reflect, tune and adjust", as the Agile Manifesto principle decrees.
Add "Project Weather" to your retrospective design to both "Set the Stage" and "Close the Retrospective". As an opening, it provides a useful segue into creating a shared story and begins the process of gathering data. As a closing, it illustrates any shifts in team members' perspectives that have occurred as a result of their collaboration in the retrospective.
Create a pre-drawn flip chart with a heading at the top: Project Weather. Add hand drawn graphics across the top, like a sun coming out from behind clouds, clouds and rain, or even the occasional tornado! Divide the flip chart...