An agile team's most distinguishing characteristic is that it continuously improves. Getting better is not unique to agile teams. After all, non-agile teams can improve as well. For an agile team, however, continuous improvement is not an option. It is a defining attribute. A team that is not improving is not an agile team…Read More
Notes from the field...
When I tell someone I am an agile coach, I sometimes receive a puzzled response.
"Oh? What sport?"... or
"Is that the thing where you train a dog to run an obstacle course?"
When I explain that I coach people and teams that create innovative products and services, they get even more confused.
"Why do they need a coach? Aren't they professionals? Don't they know their stuff? Shouldn't we reasonably expect that they can get the job done?"...Read More
Organizations steeped in a command and control hierarchical culture sometimes struggle with the concept of a self-organizing team. Releasing "control" to the team is a scary leap of faith and not a leap to be undertaken without proper preparation. Before setting a team loose to find it's own way, here are 4 critical things to put in place to increase the chances of having a successful self-organizing team.
- Shared Goal - Establish a shared understanding of the goal. A shared goal focuses the the team members' energies in the same direction. This laser-like focus leads to quick, targeted results. The shared goal is an essential container for a self-organizing team's creativity, setting both boundaries and direction. Absent an effective container, prepare for chaos.
- Dedication - Ensure that each team member is fully available to the team. Part-time is only acceptable if it does not create impediments to the teams' progress (in practice, it is rare that part-time availability does not impede flow). Dedicate space, equipment, and tools so these resources are always available without delay when needed. Waiting kills momentum and focus.
- The Right Stuff - Staff the team with a mix of people that in combination have the appropriate level of knowledge, skills, expertise, leadership, and accountability to get the job done. Attitude and aptitude play a big role as well. Also, provide the things the team needs to do the job including workspace, tools, and equipment. Don't starve the team!
- A Sense of Urgency - Give a deadline, leaning towards a shorter timeframe. Agile frameworks impose short iterations during which real, meaningful, and measurable progress is made towards the goal. Deadlines encourage action. As Samuel Johnson said, "Depend upon it, sir, when a man knows he is to be hanged in a fortnight, it concentrates the mind wonderfully."
And finally, listen and respond to the team's needs. A team starting out is never perfectly staffed and outfitted despite best efforts. If a team discovers a way to improve and needs help to implement the improvement, give them the help they need. With the proper ingredients for success, self-organizing teams thrive and become a powerful, nimble, and effective engine for delivery.
Jeff Sutherland led the team that invented Scrum at Easel Corporation in 1993 as a response to daunting request to replace all of the company's products with a single product -- within 6 months! In the couple of decades since this first Scrum team, the Scrum framework has become the most predominant Agile development approach in the world. Scrum has become so popular that there are frequent calls to apply Scrum beyond software. After all, why should the software development folks have all the fun? What I find interesting is that Scrum has in some ways come full circle. Sutherland writes in The Scrum Papers that Scrum was born of complex adaptive systems (ant colonies, flocks of birds, etc.), lean thinking (Toyota, Honda), knowledge management strategy (Takeuchi and Nonaka (The New New Product Development Game, HBR 1986) and Peter Senge (organizational learning). These disciplines, absent from most software development teams in the early 1990's, are now ubiquitous among those software teams practicing Agile development.
But, wait a minute! If these practices were rare in early 1990's software development, where were they? As Takeuchi and Nonaka's 1986 HBR article point outs, the best product development organizations in the world were using the seeds of Scrum to create... products!... such as copiers, cameras, engines. It's right there in article title: "The New New Product Development Game".
Now, back to Agile... the Agile software development movement has sometimes forgotten that software is not always the whole product. While Takeuchi and Nonaka's exemplary products might make use of software, the product whole is a sum of its parts. Software alone does not make the product work.
Lean thinking (another Agile seed) would tell us to consider the whole value stream. The value stream considers everything that must happen along the way from the initial idea to the working product. Software is rarely the only item in the stream. The fundamental elements of Scrum (inspect, adapt, and transparency) and the practices (prioritization, planning, synchronization, review, retrospective) are not exclusive to the software development aspects of the value stream. In fact, the value stream could contain no instance of software development and Scrum could still add value.
What it comes down to is this: Scrum is a team-based framework to develop complex systems and products. If this sounds like a fit for you and your team, give it a try. Software is optional.